[FFmpeg-devel] Compatibility of different library versions (was: avformat: Add internal flags for AV(In|Out)putFormat)

[James Almer]

On 6/16/2021 7:14 PM, Nicolas George wrote:
> James Almer (12021-06-16):
>> I'm not sure what you mean. I would not be against it, it's just that if we
>> were to merge lavf and lavd, this wouldn't even be something to consider.
> 
> Have you not read the discussion? The benefits go way beyond the tiny
> lavf-lavd issues.
> 
>>> and why you are
>>> against for other libraries.
>> Can you be more specific?
> 
> When I say "I am for X" and you reply "I am not against Y", with Y⊂X and
> Y≠X, you are implicitly saying that you are against X∖Y. I proposed to
> restrict to matching versions on all libraries, you replied you were not
> against restricting for lavf-lavd, stating implicitly that you are
> against it for the libraries.

Considering this discussion started about lavd and lavf, and at no point 
in your email you said "all libraries" when suggesting version locking 
anything (In fact, you mistakenly wrote "only versions from the same 
version"), i figured it would be obvious i was commenting specifically 
about lavd<->lavf.

> 
> So, I ask explicitly: are you against restricting to matching versions
> for all the libraries? If so, then why?

Of course i am against doing so for all libraries. They are already 
locked at the major soname level as required, and that's enough.
Lavd as is is locking certain lavf's public structs and making it 
impossible to add new fields to them, which constricts development 
considerably, so making their locking strict to at least the minor 
soname level is a very good idea. But this isn't an issue at all for 
other libraries.
I can add new fields to any public lavc struct, compile it and have a 
lavf that was linked to an old lavc use it at runtime, and it will work 
just fine.
I see no benefit to your suggestion that's worth removing such freedom 
from the end user.