On 05.08.2015 22:07, Reimar Döffinger wrote: > On 05.08.2015, at 21:31, Andreas Cadhalpun <andreas.cadhal...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
