On Mon, Jan 29, 2024 at 02:20:00PM +0300, Andrew Randrianasulu wrote:
> пн, 29 янв. 2024 г., 13:55 Anton Khirnov <anton@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 also have always advocated longer support for APIs/ABIs but many developers
who work on cleanups prefer shorter periods which is understandable too

Personally i would also favour if APIs/ABIs are only removed when keeping them
causes work. Often old API/ABI just needs a simple wraper around new API that
has no dependancy on anything else than the new API working as documented.

In other cases where there is risk that API/ABI might break in ways not readily
detectable, quick removial makes sense though

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras