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 CC01C445BF for ; Wed, 18 Jan 2023 21:23:52 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id EDC4568B6B1; Wed, 18 Jan 2023 23:23:49 +0200 (EET) Received: from mail-oa1-f52.google.com (mail-oa1-f52.google.com [209.85.160.52]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 69A6868041B for ; Wed, 18 Jan 2023 23:23:43 +0200 (EET) Received: by mail-oa1-f52.google.com with SMTP id 586e51a60fabf-1433ef3b61fso379431fac.10 for ; Wed, 18 Jan 2023 13:23:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=GbavIIfklKP8Qe11Q616dXuTCrzEfdjCxfcEfUFa14Y=; b=fBczQ4wI77M6kmwnABb1/ZNktMWYvOWVww6GAC1J11XcHa57HSDbpZlE9mrljhkmyG y3Okq8cNmWDR6C7UbqouEwejC2A7M217tC3YJR5kGeaZHYl0edhfy4jhX7rGDTTsG7V2 ORzsbTYciNhWjbuc6vG4h34m2608ImYNgsIOMtOmFX0L5zUrlc+JtwZ8J3JY2ehewLCl bi8yY4JRxFjt1mwiOgjeGt5B1ChkjfhVJ8X2NH7xtAPQTXWt/61yBYea4DFCTPkM8Vjf OZfQ77SG/dD/SMP50XaBvDlYFNMF2T05pWHkB5KbLt7ZeGmRqqFfMc9fkYc8skb7VX+w 4xUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=GbavIIfklKP8Qe11Q616dXuTCrzEfdjCxfcEfUFa14Y=; b=snjvGnE54/f9WvKx+2xk4pF3tDjWw0PUPbfWfmV6hJD3Y+cxT8hUdPXiyZ2qBZQtNh SxQvt0cBIhoF0YVqbPmSaLY0vaR/kSa69Emb5PPnH266P7vjB6GpApYtar+U5P3ruNNi /eCJcy5yLqiCLhMpnBM873HAEHKcooaTteboku8hVqwGw7CTXwOUSGLvEAQHidJ/X14v SrzCpWg0lkThncS8CHO2yPG59Uljm33AhHS3J76PRfZ04c+NgbaKd2b6tj4SZvGLS1eX NlVdsV9Xx5npFQhzghKJLsLvDp/moBHSu6sH6UEo/RxtLFGZ0YatUrWTcFzT5bTeU4Ax XXTA== X-Gm-Message-State: AFqh2kpdWEMGQuKMBD8E6PdaYllcZ+AnIz9PmeAKs4dSZ12vpf7rLZ8F wj0DNt62jmGntSkYaZ/KWZEZfP+/YmY= X-Google-Smtp-Source: AMrXdXvVPhGcj4Xz0Daim5yAH32oSBd4dqdfy1RycMkjar+YAK2kS9zxBomHT7MztfQwrvjSQ6QDsw== X-Received: by 2002:a05:6870:6a91:b0:15e:d91b:1a89 with SMTP id mv17-20020a0568706a9100b0015ed91b1a89mr5031894oab.5.1674077021607; Wed, 18 Jan 2023 13:23:41 -0800 (PST) Received: from [192.168.0.14] (host197.190-225-105.telecom.net.ar. [190.225.105.197]) by smtp.gmail.com with ESMTPSA id g6-20020a4aa706000000b004f9cd1e42d3sm2676558oom.26.2023.01.18.13.23.40 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 18 Jan 2023 13:23:41 -0800 (PST) Message-ID: Date: Wed, 18 Jan 2023 18:23:43 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Content-Language: en-US To: ffmpeg-devel@ffmpeg.org References: <20230116133840.512-1-jamrial@gmail.com> <167407008302.4503.12911207010634660934@lain.khirnov.net> From: James Almer In-Reply-To: <167407008302.4503.12911207010634660934@lain.khirnov.net> 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: 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 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). 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'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. > _______________________________________________ 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".