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

[Anton Khirnov]

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. 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