пн, 29 янв. 2024 г., 13:55 Anton Khirnov <an...@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 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 > _______________________________________________ > 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". > _______________________________________________ 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".