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. @item Performing ABI- but not API-breaking changes, like reordering struct contents. -- 2.42.0 _______________________________________________ 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".
