[FFmpeg-devel] [libav-devel] [PATCH 0/20] removal of deprecated features

[Andreas Cadhalpun]

On 05.08.2015 22:07, Reimar Döffinger wrote:
> On 05.08.2015, at 21:31, Andreas Cadhalpun <andreas.cadhalpun at googlemail.com> wrote:
>>> Btw. the magic option to enable compatibility is still somewhat useful as it lists
>>> and allows testing the specific changes that are coming up. But I agree it's only
>>> a minor help.
>>
>> The problem with such a magic option is that it combines the disadvantages of
>> removing and not removing: Programs using the old API get broken by default
>> and the deprecated functionality remains in the code base.
> 
> TLDR: the real advantage would be support for test automation.

If it's broken by default, it's not really good for testing.

> Maybe the default should be the other way round,

That's an essential difference.

> but I think you are missing the point.
> How otherwise will you tell people what will be removed for the next release?

Maybe mention it in the release notes?

> Documentation? Nobody reads it until they have a problem.

How should one find out about a magic option if one doesn't read the documentation?

> Mailing list? Nobody has time to read that amount of traffic.
> (feel free to put "nobody" in quotation marks in your mind)
> Just wait until the release and watch the panic as everyone has to hurry to support it?
> Even if everyone knew what was going to be removed, how would they test?
> Manually editing files??
> For those who have a proper setup with testing, such an option would just mean having a
> configuration with it set to test upcoming removals (and never have to edit that
> configuration, to e.g. manually set what to remove).

One could already '#define LIB*_MAJOR_VERSION 100' for testing the deprecations.

> Sure, it would be broken much of the time probably, but run e.g. "make -k" and you have
> an idea how bad it is, you can piece by piece work on fixing it, have a time plan to have
> it pass by the time the next release is due, complain to us if there is something you don't
> think is reasonable etc.
> And except for the "broken much of the time", we are one of those users that could use
> it ourselves.
> Or has anyone who proposed removals ever tested on anything even approaching our full
> FATE test (in particular different architectures)?

Such an option might be useful, but I wouldn't rely on many using it.

Best regards,
Andreas