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

[Anton Khirnov]

Quoting Andrew Randrianasulu (2024-01-29 12:20:00)
> пн, 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.

We know that API breaks are a burden for users, but they are necessary.
We don't break API just for fun.

And the point of this thread is not whether we should have API breaks at
all, but how long to keep deprecated APIs.

-- 
Anton Khirnov