On 31.07.2015, at 17:47, Nicolas George <geo...@nsup.org> wrote: > I can propose the following middle term:
I do have on more proposal, but the problem is it needs someone to do the work. For each removed feature, prepare documentation "a monkey could follow" on how to replace it (you could call it a transition guide). Even better, a script that automates it where reasonable. In some cases it is just a matter of copy-pasting some existing wrapper code, particularly if we remove that wrapper code it is useful if people still have it available in the new release. If it's just a few hours of someone's time who even doesn't need to understand the code, I think we can very confidently say "not really our problem" if some applications still use it. If we that way find out that there are non-trivial cases or cases where the code gets a lot more complicated it might be a hint the new API is still crap and we maybe should come up with something better first. 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. Regards, Reimar _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
