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. > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >
I'd be more comfortable with 59, that should save effort on the part of the person doing the bump. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel