[FFmpeg-devel] [PATCH 04/13] lavc: Deprecate av_hwaccel_next() and av_register_hwaccel()

[Mark Thompson]

On 18/11/17 20:18, Rostislav Pehlivanov wrote:
> On 18 November 2017 at 20:11, James Almer <jamrial at gmail.com> wrote:
> 
>> On 11/18/2017 5:03 PM, Rostislav Pehlivanov wrote:
>>> On 18 November 2017 at 19:17, James Almer <jamrial at gmail.com> wrote:
>>>
>>>> On 11/18/2017 4:07 PM, Mark Thompson wrote:
>>>>> On 18/11/17 19:00, Rostislav Pehlivanov wrote:
>>>>>> On 18 November 2017 at 18:47, Mark Thompson <sw at jkqxz.net> wrote:
>>>>>>
>>>>>>> ---
>>>>>>>  doc/APIchanges       |  4 ++++
>>>>>>>  libavcodec/avcodec.h | 13 +++++++++++++
>>>>>>>  libavcodec/utils.c   | 16 +++++-----------
>>>>>>>  libavcodec/version.h |  3 +++
>>>>>>>  4 files changed, 25 insertions(+), 11 deletions(-)
>>>>>>>
>>>>>>>
>>>>>>>  int av_lockmgr_register(int (*cb)(void **mutex, enum AVLockOp op))
>>>>>>>  {
>>>>>>> diff --git a/libavcodec/version.h b/libavcodec/version.h
>>>>>>> index 5b25a9a8ac..693f67386c 100644
>>>>>>> --- a/libavcodec/version.h
>>>>>>> +++ b/libavcodec/version.h
>>>>>>> @@ -123,6 +123,9 @@
>>>>>>>  #ifndef FF_API_CODEC_GET_SET
>>>>>>>  #define FF_API_CODEC_GET_SET     (LIBAVCODEC_VERSION_MAJOR < 59)
>>>>>>>  #endif
>>>>>>> +#ifndef FF_API_USER_VISIBLE_AVHWACCEL
>>>>>>> +#define FF_API_USER_VISIBLE_AVHWACCEL (LIBAVCODEC_VERSION_MAJOR <
>> 60)
>>>>>>>
>>>>>>
>>>>>> 60? That's 2 bumps away, this should be 59, no?
>>>>>
>>>>> Two bumps away is the usual number, isn't it?  Or does it count as
>>>> not-bumped-yet for this purpose because we are still in the unstable
>> period?
>>>>
>>>> The number doesn't matter as long as the condition evaluates to true
>>>> when it's meant to.
>>>> If you use 59 and there's a bump before the two years period for this
>>>> specific deprecation is over, then the line will have to be changed to
>>>> 60 during said bump to make sure the API doesn't get disabled.
>>>> However using 60 would mean that the line can be left alone. The bump
>>>> that changes the major to 60 is unlikely to happen before the two year
>>>> mark.
>>>>
>>>> So it's fine as is. No need to change it.
>>>>
>>>>
>>> It'll be forgotten and it'll take 4 years to remove. How is anyone
>> supposed
>>> to know when something's meant to be removed aside from the MAJOR
>> version?
>>
>> By git blaming version.h to look at the exact date of the commits that
>> deprecated every listed API, same as it's done every time a bump takes
>> place.
>>
>> As long as whoever handles the bump does it properly then it shouldn't
>> make a difference. But if you feel more comfortable making it 59 then it
>> can be changed. Both values are fine.
>>
> 
> I'd be more comfortable with 59, that should save effort on the part of the
> person doing the bump.

Ok, changed to 59.

Thanks,

- Mark