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

[James Almer]

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.