On 18/11/17 20:18, Rostislav Pehlivanov wrote: > On 18 November 2017 at 20:11, James Almer <jamr...@gmail.com> wrote: > >> On 11/18/2017 5:03 PM, Rostislav Pehlivanov wrote: >>> On 18 November 2017 at 19:17, James Almer <jamr...@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 <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. >>>> >>>> >>> 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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel