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 9990143391 for ; Wed, 8 Jun 2022 17:38:23 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 5338268B67B; Wed, 8 Jun 2022 20:38:21 +0300 (EEST) Received: from mail0.khirnov.net (red.khirnov.net [176.97.15.12]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 1770068B000 for ; Wed, 8 Jun 2022 20:38:15 +0300 (EEST) Received: from localhost (localhost [IPv6:::1]) by mail0.khirnov.net (Postfix) with ESMTP id 8B5B4240175 for ; Wed, 8 Jun 2022 19:38:14 +0200 (CEST) Received: from mail0.khirnov.net ([IPv6:::1]) by localhost (mail0.khirnov.net [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 3v92zgAoOqLe for ; Wed, 8 Jun 2022 19:38:13 +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 DFA492400F5 for ; Wed, 8 Jun 2022 19:38:13 +0200 (CEST) Received: by lain.khirnov.net (Postfix, from userid 1000) id 1F3861601B2; Wed, 8 Jun 2022 19:38:14 +0200 (CEST) From: Anton Khirnov To: FFmpeg development discussions and patches In-Reply-To: =?utf-8?q?=3CDM8P223MB03650A071143B1B0941BEBE7BAA49=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?= <165469059933.5088.676378891981541783@lain.khirnov.net> =?utf-8?q?=3CDM8P22?= =?utf-8?q?3MB03650A071143B1B0941BEBE7BAA49=40DM8P223MB0365=2ENAMP223=2EPROD?= =?utf-8?q?=2EOUTLOOK=2ECOM=3E?= Mail-Followup-To: FFmpeg development discussions and patches Date: Wed, 08 Jun 2022 19:38:14 +0200 Message-ID: <165470989408.5088.14566997065698893831@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 17:38:31) > > 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. > > Not any change, but for a change in output, I'd say yes. I mean - isn't that > what FATE is checking? And don't you say "breaks FATE" when the an output > changes? We generally do not make hard guarantees about the output produced by the libraries, otherwise almost everything would be a compatibility break (e.g. adding support for previously unimplemented codec or container features). We only promise to make best effort to produce "sensible" output, where "sensible" has no strict definition and is subject to discussion and consensus among developers. In this case, I argued that previous behavior was a bug and nobody disagreed so far. "breaks FATE" is a shortcut, it means only that the output has changed. That may be because a change broke something, but it also happens that there is a legitimate reason for the output changing, then the test references are simply updated. > > After all, I'm still having a hard time in assimilating the logic and mindsets > here. I'm obviously coming from a very different background and certain things > just don't make sense to me, so I have to ask many questions, when I can't > believe it, I ask once again, and again and re-assure that it's really that > way that I can hardly believe. When the versions do not guarantee anything > besides API compatibility, then there's almost not practical value in having > them, because things can always go wrong no matter whether those versions > match or not as you always need to test thoroughly. You would be able > to rule out some combinations up-front, but that's it. > Also, given that fact that matching versions do not guarantee anything of > practical value, who would then still want to mix ffmpeg libs from different > Git revisions based on those version numbers? I can't compute this ;-) API compatibility is of great practical value to many people. To the contrary, I'd say that absolute output stability is far less important to most our users. -- 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".