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) thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein
signature.asc
Description: PGP signature
_______________________________________________ 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".
