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