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

[Vittorio Giovara]

On Sun, Jan 28, 2024 at 11:47 PM Michael Niedermayer <michael at niedermayer.cc>
wrote:

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

IMO that's a bit verbose and given language is not precise it could lead to
confusion (at least 1 year from deprecation? from a release with a
deprecation warning? a mix of the two?)
I find extremely unlikely that there will be two major releases, and these
are supposed to be guidelines so I'm sure that even in that event we could
reasonably delay things if needed
-- 
Vittorio