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

[Reimar Döffinger]

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.
Maybe the default should be the other way round, but I think you are missing the point.
How otherwise will you tell people what will be removed for the next release?
Documentation? Nobody reads it until they have a problem.
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).
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)?