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 B03E444D24 for ; Wed, 18 Jan 2023 19:28:13 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id BB9A668B41A; Wed, 18 Jan 2023 21:28:10 +0200 (EET) Received: from mail0.khirnov.net (red.khirnov.net [176.97.15.12]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 6809C68A9C1 for ; Wed, 18 Jan 2023 21:28:04 +0200 (EET) Received: from localhost (localhost [IPv6:::1]) by mail0.khirnov.net (Postfix) with ESMTP id F1581240183 for ; Wed, 18 Jan 2023 20:28:03 +0100 (CET) Received: from mail0.khirnov.net ([IPv6:::1]) by localhost (mail0.khirnov.net [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id ed_gYjq9a4uC for ; Wed, 18 Jan 2023 20:28:03 +0100 (CET) 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 2E84B2400F5 for ; Wed, 18 Jan 2023 20:28:03 +0100 (CET) Received: by lain.khirnov.net (Postfix, from userid 1000) id 0EFCA1601B2; Wed, 18 Jan 2023 20:28:03 +0100 (CET) From: Anton Khirnov To: FFmpeg development discussions and patches In-Reply-To: <20230116133840.512-1-jamrial@gmail.com> References: <20230116133840.512-1-jamrial@gmail.com> Mail-Followup-To: FFmpeg development discussions and patches Date: Wed, 18 Jan 2023 20:28:03 +0100 Message-ID: <167407008302.4503.12911207010634660934@lain.khirnov.net> User-Agent: alot/0.8.1 MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH 00/26] Major library version bump 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 James Almer (2023-01-16 14:38:14) > It's been a while since the last bump, so it's time to do some cleaning and > remove deprecated APIs. This will also give us an "Open ABI season" in which we > can do breaking changes (like changing public struct offsets, public enum > values, adding fields to structs that have their size tied to the ABI, etc) for > a few weeks. Last time this open season lasted something like half a year and only ended when I arbitrarily said it did. So I'd suggest to decide right now how long will the instability period last (6 weeks should be enough for everybody) and write the end date at the top of doc/APIchanges. Another thing I'm not entirely happy about is versioning during the bump and instability. While the remove-then-bump approach does make bisection easier, it also creates commits that lie about their ABI version. I wonder if we couldn't come up with a better soltion. One thing that comes to mind is setting the major version to 0 until the instability period ends. > I'm also taking this opportunity to suggest a change in our deprecation period > policy. Until now it's been a generic two years period, with no concrete reason > for it other than giving library users "time" to migrate. What we have seen > however is that users migrate in two cases: As soon as things are deprecated > when they use git head to get rid of deprecation warnings, or when they have no > choice (aka, when they want to move their project to a new ffmpeg version that > no longer has the symbols they depended on). > In the latter case, any arbitrary amount of time will make no difference > whatsoever. Projects could right now still be using ffmpeg 4.3 (since that's > what Debian stable ships) and would not consider moving to 5.1 or any future > version for the foreseeable future. So the suggestion is to change to a release > based scheme, which will in some form be time based anyway. Namely, every three > releases we do a major bump, which will be a good year or so in real world > terms, in which all API deprecated during that period, as long as it's present > in a release, is removed. This would also go with the idea of a recurrent LTS > release, so if we do three releases per major version, it could be x.0 (initial > release) x.1 (LTS), and x.2 (last release made pre bump). Sounds good to me. > If we go the above route, we could also remove API like the old lavu FIFO stuff, > a deprecation that's slightly less than a year old but effectively present in > v5.1. > We'd also need to add all this in writing, because this kind of policy can't > just be "oh yeah, we do it that way" in random emails. But folklore is the most time-tested method of transmitting information. -- 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".