Re: [FFmpeg-devel] [PATCH] lavf/matroskadec: stop mapping text/plain attachments to AV_CODEC_ID_TEXT

[Soft Works <softworkz@hotmail.com>]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Anton
> Khirnov
> Sent: Wednesday, June 8, 2022 2:17 PM
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] lavf/matroskadec: stop mapping text/plain
> attachments to AV_CODEC_ID_TEXT
> 
> 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.

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?

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 ;-)

But I also don't want to annoy you endlessly, so rather let me say 
thank you for your patience and for explaining your view on 
these things.

Best wishes,
sw







_______________________________________________
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".