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 A5FF042E10 for ; Wed, 8 Jun 2022 12:16:53 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id F15C968B6D9; Wed, 8 Jun 2022 15:16:50 +0300 (EEST) Received: from mail0.khirnov.net (red.khirnov.net [176.97.15.12]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 602DB68B1E6 for ; Wed, 8 Jun 2022 15:16:44 +0300 (EEST) Received: from localhost (localhost [IPv6:::1]) by mail0.khirnov.net (Postfix) with ESMTP id 3DA5A240175 for ; Wed, 8 Jun 2022 14:16:43 +0200 (CEST) Received: from mail0.khirnov.net ([IPv6:::1]) by localhost (mail0.khirnov.net [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id Ph3RwaYMdINJ for ; Wed, 8 Jun 2022 14:16:42 +0200 (CEST) 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 710372400F5 for ; Wed, 8 Jun 2022 14:16:42 +0200 (CEST) Received: by lain.khirnov.net (Postfix, from userid 1000) id 5ADDC1601B2; Wed, 8 Jun 2022 14:16:39 +0200 (CEST) From: Anton Khirnov To: FFmpeg development discussions and patches In-Reply-To: =?utf-8?q?=3CDM8P223MB0365D3CD0072AAFA97FDC20ABAA49=40DM8P223MB?= =?utf-8?q?0365=2ENAMP223=2EPROD=2EOUTLOOK=2ECOM=3E?= References: <20220607115839.18515-1-anton@khirnov.net> =?utf-8?q?=3CDM8P223M?= =?utf-8?q?B03650454F09DE4D7C396CFB4BAA49=40DM8P223MB0365=2ENAMP223=2EPROD?= =?utf-8?q?=2EOUTLOOK=2ECOM=3E_=3CDM8P223MB0365397786EAF497BA5DC577BAA49=40D?= =?utf-8?q?M8P223MB0365=2ENAMP223=2EPROD=2EOUTLOOK=2ECOM=3E?= <165466902879.5088.14253593912707356675@lain.khirnov.net> =?utf-8?q?=3CDM8P?= =?utf-8?q?223MB036505AC3D4B249D6F66F803BAA49=40DM8P223MB0365=2ENAMP223=2EPR?= =?utf-8?q?OD=2EOUTLOOK=2ECOM=3E?= <165467214169.13099.10591659789295187077@lain> =?utf-8?q?=3CDM8P223MB0365F9?= =?utf-8?q?5C1E9F2C9C4222BDF6BAA49=40DM8P223MB0365=2ENAMP223=2EPROD=2EOUTLOO?= =?utf-8?q?K=2ECOM=3E?= <165467548837.5088.14494376448659698736@lain.khirnov.net> =?utf-8?q?=3CDM8P?= =?utf-8?q?223MB0365D3CD0072AAFA97FDC20ABAA49=40DM8P223MB0365=2ENAMP223=2EPR?= =?utf-8?q?OD=2EOUTLOOK=2ECOM=3E?= Mail-Followup-To: FFmpeg development discussions and patches Date: Wed, 08 Jun 2022 14:16:39 +0200 Message-ID: <165469059933.5088.676378891981541783@lain.khirnov.net> User-Agent: alot/0.8.1 MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH] lavf/matroskadec: stop mapping text/plain attachments to AV_CODEC_ID_TEXT 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 Soft Works (2022-06-08 10:34:05) > > > I don't think it's absurd, neither hypothetical to ask whether somebody, > > > would object a certain change --- BEFORE working spending time on it. > > > > It does makes sense to consider it, but at some point you have to accept > > that ANY change you make can possibly break somebody's use case. So > > being overly considerate means no useful development gets done. > > I very much agree to this. But I'm wondering how this can go together > with versioning the code by 24 different numbers (8 libs * 3 integers). > Even when you make a change that is undoubtedly correct and justified and > right - when it changes behavior it breaks compatibility, even when the > previous behavior was totally bad and wrong. > > Once you leave that path and replace it by some "custom" judgement with regards > to what's compatible and what's breaking and consider a change to be non-breaking > because it changes only "illegitimate" behavior, it's still a breaking and > incompatible change. > When it's not possible to rely on a precise and strict compatibility based > on these version numbers with major, minor and micro for every single lib, > and you say - nevermind, every change will break something, what are all > those numbers for? They would be pointless, wouldn't they? Those numbers are not "code version", they are "API version". They do not provide guarantees on specific code behavior, they provide guarantees on what APIs are available and their semantics. > > When we add a new codec ID, what was previously "none" changes to an > > actual codec name. Users for whom any change at all is a problem should > > simply not update their binaries. > > How should those users know when the library version numbering doesn't > indicate that breaking change? Tests. Lots of tests. If any change in behaviour is a breaking change for you, then git commit hash is the library version you should use. -- 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".