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 D615344FF5 for ; Thu, 19 Jan 2023 07:26:58 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 5D53A68B6E2; Thu, 19 Jan 2023 09:26:54 +0200 (EET) Received: from mail0.khirnov.net (red.khirnov.net [176.97.15.12]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id CAE25689965 for ; Thu, 19 Jan 2023 09:26:47 +0200 (EET) Received: from localhost (localhost [IPv6:::1]) by mail0.khirnov.net (Postfix) with ESMTP id 59F7D240183 for ; Thu, 19 Jan 2023 08:26:47 +0100 (CET) Received: from mail0.khirnov.net ([IPv6:::1]) by localhost (mail0.khirnov.net [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id ew2uYqSyLzSU for ; Thu, 19 Jan 2023 08:26:46 +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 B06202400F5 for ; Thu, 19 Jan 2023 08:26:46 +0100 (CET) Received: by lain.khirnov.net (Postfix, from userid 1000) id 993C41601B2; Thu, 19 Jan 2023 08:26:46 +0100 (CET) From: Anton Khirnov To: FFmpeg development discussions and patches In-Reply-To: References: <20230116133840.512-1-jamrial@gmail.com> <167407008302.4503.12911207010634660934@lain.khirnov.net> Mail-Followup-To: FFmpeg development discussions and patches Date: Thu, 19 Jan 2023 08:26:46 +0100 Message-ID: <167411320660.26119.4058197378126067958@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-18 22:23:43) > On 1/18/2023 4:28 PM, Anton Khirnov wrote: > > 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. > > Does it really matter? All the patches will be pushed at the same time, > meaning one git fetch will give you a stable state pre bump and the next > will be right after it. > I think it's a bit farfetched to expect someone to pick a random commit > in the middle of the bump and try to use the resulting compiled > libraries with some program that was linked to some earlier version > libraries. I agree that it's probably not a big practical problem, but it is ugly and goes against our claims of git master being stable. > > 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. > > This could have several undesired effects, mainly for users looking at > that define and not really expecting such value (There are several > projects supporting more than one ffmpeg release and "MAJOR <= xx" > checks are commonplace). IMO users who don't expect such a value shouldn't be linking against unstable API/ABI anyway. We could also set the major version to something really big, like 999. We'll have to change deprecation macros, but that should be straightforward. > Also, if we are going to code the instability period in some form into > the codebase, might as well make it so it starts with the first removal > commit, or immediately before it, so what you described above is no > longer a concern. I'd rather say the two concerns merge into one, but it's not going away. There's currently very little user indication that API/ABI are unstable for several months. -- 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".