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 BF3FE4B353 for ; Tue, 4 Jun 2024 08:35:12 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 4527168D6C2; Tue, 4 Jun 2024 11:35:09 +0300 (EEST) Received: from b-painless.mh.aa.net.uk (b-painless.mh.aa.net.uk [81.187.30.52]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 5F51A68D6B1 for ; Tue, 4 Jun 2024 11:35:03 +0300 (EEST) Received: from 0.c.a.4.e.5.3.2.5.8.5.6.7.e.1.c.0.5.8.0.9.1.8.0.0.b.8.0.1.0.0.2.ip6.arpa ([2001:8b0:819:850:c1e7:6585:235e:4ac0] helo=andrews-2024-laptop.sayers) by painless-b.tch.aa.net.uk with smtp (Exim 4.96) (envelope-from ) id 1sEPdG-001NDV-1x for ffmpeg-devel@ffmpeg.org; Tue, 04 Jun 2024 09:35:02 +0100 Date: Tue, 4 Jun 2024 09:34:52 +0100 From: Andrew Sayers To: FFmpeg development discussions and patches Message-ID: References: <20240123192241.GA6420@pb2> <20240302225538.GI6420@pb2> <20240302231928.GJ6420@pb2> <20240603213237.GC2821752@pb2> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20240603213237.GC2821752@pb2> Subject: Re: [FFmpeg-devel] FFmpeg 7.0 blocking issues 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: On Mon, Jun 03, 2024 at 11:32:37PM +0200, Michael Niedermayer wrote: > On Sun, Jun 02, 2024 at 03:49:42PM +0200, Sebastian Ramacher wrote: [...] > > Just as a FYI: ffmpeg 7.0 breaks close to 70 reverse dependencies in > > Debian. The list is available at [1]. So if you want ffmpeg X to be in > > Debian Y or Ubuntu Z, X needs to be released at least half a year before > > Y or Z freeze. > > Is there something that ffmpeg can do to reduce this breakage ? > (i know its a bit of a lame question as its API brekages but i mean > can the policy we have about deprecating API/ABI be amended in some way > to make this easier ? A quick look through Sebastian's list suggests two main groups of issues: * channel layout migration * things that didn't have attribute_deprecated before being removed There are probably ways to reduce migration issues (e.g. Anton's point about frequent small changes), but the quick win is to use attribute_deprecated more. To be clear - attribute_deprecated is already used a lot. If those messages were being ignored, we would expect to see more bugs reported for those things. The fact that channel layout is the only deprecated functionality to get this far suggests that attribute_deprecated is a good way to notify people about all but the largest changes. > Also am i correct that it should be easier if a X.1 with same API/ABI that is > released 6 month after X.0 is targetet for the release ? Thats in fact kind > of what i would have preferred anyway as the .1 likely has also fewer bugs > > And last but not least, someone needs to write down when .0 and .1 releases should > be made so I dont forget it :) Whatever decision is made about this, it would be good to update the attribute_deprecated macro to point to a URL that lays out the policy. Something like: #define attribute_deprecated __attribute__((deprecated("see for details"))) _______________________________________________ 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".