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 <s...@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.
>
> - Mark
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
