From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id CFA9748E51 for ; Mon, 29 Jan 2024 10:55:49 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id C3EF368D1EC; Mon, 29 Jan 2024 12:55:47 +0200 (EET) Received: from mail0.khirnov.net (red.khirnov.net [176.97.15.12]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 076A968D05A for ; Mon, 29 Jan 2024 12:55:41 +0200 (EET) Authentication-Results: mail0.khirnov.net; dkim=pass (2048-bit key; unprotected) header.d=khirnov.net header.i=@khirnov.net header.a=rsa-sha256 header.s=mail header.b=cbrh11fb; dkim-atps=neutral Received: from localhost (localhost [IPv6:::1]) by mail0.khirnov.net (Postfix) with ESMTP id A27E52405F2 for ; Mon, 29 Jan 2024 11:55:40 +0100 (CET) Received: from mail0.khirnov.net ([IPv6:::1]) by localhost (mail0.khirnov.net [IPv6:::1]) (amavis, port 10024) with ESMTP id ohv_QCPkdFOu for ; Mon, 29 Jan 2024 11:55:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=khirnov.net; s=mail; t=1706525739; bh=VJBMcSjuFgvnz0AM/5fGVNemuiWZLo/qHSDwjB4E0L4=; h=Subject:From:To:In-Reply-To:References:Date:From; b=cbrh11fb/c3rWYz4vcas3n6PZ80TEuO+LYT0QTM5sNVDStt6CxSkDVO/NvmaNifWv ZlB6NDqyjl+9PAG3USg5jGL51xXEWhuAXdkakqjwyxhy75IXadylcIAe7PJB9mhfQ+ MtZ7mHeE0JGV/Dd4K+FW/X2Ixn1iQW5er5oLQWBwQqJUzJaWmfH4lD13F6siXiwfuW lejxMg7nVFGfb37XAjeTZf2zv8ZzFCcI8vIol61u0//LNJP9OiNCt9NSB2I5/InXhD /gjJqs7fqV3C/PRYE/6RIT1xObNnVXUyUo4QpWriS3nAvoDxTSO29e6q32joqapbAz l7Dg94d8C08lw== Received: from lain.khirnov.net (lain.khirnov.net [IPv6:2001:67c:1138:4306::3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "lain.khirnov.net", Issuer "smtp.khirnov.net SMTP CA" (verified OK)) by mail0.khirnov.net (Postfix) with ESMTPS id ED8162404E5 for ; Mon, 29 Jan 2024 11:55:39 +0100 (CET) Received: by lain.khirnov.net (Postfix, from userid 1000) id C8A041601B9; Mon, 29 Jan 2024 11:55:33 +0100 (CET) From: Anton Khirnov To: FFmpeg development discussions and patches In-Reply-To: <20240128224706.GU6420@pb2> References: <20240128122944.10889-1-anton@khirnov.net> <20240128224706.GU6420@pb2> Mail-Followup-To: FFmpeg development discussions and patches Date: Mon, 29 Jan 2024 11:55:33 +0100 Message-ID: <170652573379.8914.11462532687325679301@lain.khirnov.net> User-Agent: alot/0.8.1 MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [RFC/PATCH] doc/developer: clarify the criterion for removing deprecated APIs X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: 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. 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-request@ffmpeg.org with subject "unsubscribe".