On Tue, 4 Aug 2015 07:57:34 +0200 Reimar Döffinger <reimar.doeffin...@gmx.de> wrote:
> 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). Yes, that's a good idea. We should probably require something like this from every patch that deprecates API for other APIs. There should probably be a migration guide in doc or so. Libav also tried something like it: https://wiki.libav.org/Migration/11 > Even better, a script that automates it where reasonable. Would probably work for simple renames, like the AV_ prefix additions. > 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. Well, often the problem is that such deprecated features are terribly entangled with the rest of the code. Consider AVPacket.destruct. > 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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
