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 07C2940368 for ; Thu, 19 Jan 2023 12:18:35 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 5F3E568BA8C; Thu, 19 Jan 2023 14:18:32 +0200 (EET) Received: from mail-oi1-f173.google.com (mail-oi1-f173.google.com [209.85.167.173]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 8CA3668B080 for ; Thu, 19 Jan 2023 14:18:25 +0200 (EET) Received: by mail-oi1-f173.google.com with SMTP id j130so1525079oif.4 for ; Thu, 19 Jan 2023 04:18:25 -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:content-language :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=w/fkL741PywwcTbEwk0ZCd1ncDCxCb6XQvxiBDtEjA0=; b=OKE+WB7ko14Iz1MqZ0i8q9/gYbYdSxAiOxuiTQoa0B2zrXsIfm332PUvF2VfxESEtL HYVdr7hBD1JitA3kiXzZ6gbhbtkFu7VhMxQwjI7geu6rRXi9GxhfX+dC7PWhWc7RFW9g w0GrAIwalAarfRUlWi+o/NU56VYDg1JX/bvX8HNaft3P5l22u+ON7O0a+y5EfkaVLA7l Y2+6tYla/P9Bn8PT/xei/7bOUjwJEw1HHP5p/OksVxZcvmHSJKnwl7OPQ6FOd5bH/ZOw Hs04uWUfczi1SAmR8Ymec+JOhZY8QD2+SjEdIgc0wXmBURAGxxmj9b2tgbs4B2hPhisp jZpA== 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:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=w/fkL741PywwcTbEwk0ZCd1ncDCxCb6XQvxiBDtEjA0=; b=UJPGgFf/DgTneqkbGkonP1STXj0m1CgzGz8Dmkt2lrHoa+a+ROjzg94usCePKtW16j AI/+EVxS2xNN6gl0rp0GOiGJ2isVPqP0bYIDAMSqsoWPKBsKRNeaa2cWJQp/ksDUqYUO xX7TxlgbNt2q8RTgtUZgmDZJbpfrer9sU8IbLMNrO3kRw0SjcgFLnTOTylWE7q/onU35 8lCw0gvZFk336QWtuYjYP4KtHOtN+4a/ZDPog4w5P2/sTdunxJOM8GVPRfuwjqwm79zG tDYwV3xV+8lmhzmbrP0/ZHtHwXLv61B6Tz9wd9kfqmx8+X1Wt/m0vflioq8TfHXMv0ZP hCaQ== X-Gm-Message-State: AFqh2kreL1AdBBh8NJxuof7kapAHHmI/i37JaFtH6vZMrj3Ud5kp3lKl iZL0zewo6JeozeEQ3RpV9SmVXtdRTIw= X-Google-Smtp-Source: AMrXdXvRKm0001jSvraMEaE0TZwksaqucubK0Gs1fE96P6Cz3AZCTyCzf3dlRNdoGySf9NWKS56Haw== X-Received: by 2002:a05:6808:1247:b0:360:e643:7e27 with SMTP id o7-20020a056808124700b00360e6437e27mr6186813oiv.36.1674130703392; Thu, 19 Jan 2023 04:18:23 -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 bl6-20020a056830370600b00670461b8be4sm19529368otb.33.2023.01.19.04.18.22 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 19 Jan 2023 04:18:22 -0800 (PST) Message-ID: <88e94ba0-4a33-ce0d-ce29-d0728473512e@gmail.com> Date: Thu, 19 Jan 2023 09:18:28 -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 To: ffmpeg-devel@ffmpeg.org References: <20230116133840.512-1-jamrial@gmail.com> <167407008302.4503.12911207010634660934@lain.khirnov.net> <167411320660.26119.4058197378126067958@lain.khirnov.net> Content-Language: en-US From: James Almer In-Reply-To: <167411320660.26119.4058197378126067958@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/19/2023 4:26 AM, Anton Khirnov wrote: > 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. How about making minor == 0 mean unstable? Some projects like GCC do it like this, for example. Said version would not guarantee anything at all and should not be linked against. Then once the period ends after the major bump, it's bumped to 1, and the usual "new API, minor bump" rule kicks in. This also means that any API addition that takes place during the unstable period doesn't get it's own version, and they will all strictly speaking be introduced by minor 1. As for your concern about first removing then bumping meaning we're lying about the ABI, the first commit in the set could maybe rollback minor to 0, then apply the removals, and finally the major bump in the last commit. It will that way be considered unstable for the whole thing. _______________________________________________ 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".