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