[FFmpeg-devel] [RFC/PATCH] doc/developer: clarify the criterion for removing deprecated APIs

[Andrew Randrianasulu]

пн, 29 янв. 2024 г., 13:55 Anton Khirnov <anton at khirnov.net>:

> Quoting Michael Niedermayer (2024-01-28 23:47:06)
> > On Sun, Jan 28, 2024 at 01:28:36PM +0100, Anton Khirnov wrote:
> > > Previously, the implicit standard was to wait 2 years before
> deprecation
> > > and removal, but it has been widely agreed at developer meetings that
> > > time-based measures do not make sense and we should switch to a
> > > release-based one instead.
> > > ---
> > > Feel welcome to argue for other numbers than 2, or suggest alternative
> > > criteria, but please try to limit bikeshedding.
> > > ---
> > >  doc/developer.texi | 3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/doc/developer.texi b/doc/developer.texi
> > > index dd96e3b36a..3f3218f66a 100644
> > > --- a/doc/developer.texi
> > > +++ b/doc/developer.texi
> > > @@ -552,7 +552,8 @@ the negative effects on our callers, who are
> required to adapt their code,
> > >  backward-incompatible changes during a major bump should be limited
> to:
> > >  @itemize @bullet
> > >  @item
> > > -Removing previously deprecated APIs.
> > > +Removing APIs that were marked as deprecated in at least two previous
> > > +major releases.
> >
> > Removing APIs that were marked as deprecated in at least two previous
> > major releases for at least 1 year.
> >
> > (goal of this proposed difference is to ensure that if for whatever
> reason
> >  we make several major releases in quick succession it doesnt deprecate
> >  things faster)
>
> I don't think it is a good idea, because experience shows that our users
> update either very quickly (within a few months), or wait until their
> hand is forced by the API being removed.



Just for the record: I dislike when ffmpeg breaks it for us. You may call
me incompetent, but then I'll invite you to work voluntary as maintainer of
cinelerra-gg.


I find it extremely unlikely
> that we'll need to have three major releases within a few months, so
> this rule would serve no useful purpose. It could, however, have a
> negative effect in delaying the bump and the subsequent release until we
> reach the exact one year mark. I don't think we need any extra delays in
> our release process.
>
> --
> Anton Khirnov
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>