On Sun, Jan 28, 2024 at 11:47 PM Michael Niedermayer <mich...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
