On Fri, Jul 31, 2015 at 5:47 PM, Nicolas George <geo...@nsup.org> wrote: > Le tridi 13 thermidor, an CCXXIII, Hendrik Leppkes a écrit : >> They have had 2-3 years to update, what makes you think they will ever >> if we don't force them at some point? > > What makes you think they will ever do it even if we try to force them? They > will just stick to an older version of FFmpeg, and that would be worse for > everyone else. Well, not all would do that, but some of them, too many, > would. > >> Removing it not only serves some purpose of "cleanlyness" as some >> people like to pretend, but it actually removes a whole bunch of >> problems which new users of the API commonly run into because they >> accidentally use the old API (usually because some ancient example >> they found used it as well). >> Not having this old and wrong API at all anymore will prevent a lot of >> these cases and instead help guide the users towards the new and >> properly-working and tested API. > > I can propose the following middle term: > > - Making the old features disabled by default but very easy to enable if you > know how. A single #include <libavutil/depcrecated_api.h>, for example, or > a header that needs to be replaced by another manually at install time > (packagers can use a diversion mechanism to create a > "ffmpeg-deprecated-dev" package). > > - The features stay there but are utterly unsupported. If there is a bug, do > not fix it. If there is a security issue, a build failure or anything of > the kind, or if it makes it harder to add new features, remove anything in > the way. If it breaks third party projects, not our problem. > > The second point is nice, because it is the least effort policy: we do not > make effort to support the deprecated APIs, but we do not make effort to > remove them either. >
Your second point is the one thing I really would hate to see, which was also one of my arguments for removing deprecated API in the first place. What will happen is that distributions will enable it (because obscure-app-37 needs it), people will develop new apps on those distributions, and accidentally use this old broken API in their new code, because they are just following some ancient example code they found on the interwebs somewhere. On top of that, having code with known problems, even worse, security problems, is just a Bad Idea. If we offer an API, it should at least be somewhat supported, even if not tested every day due to being deprecated. If we don't want to support it anymore, and would even be willing to let it break and have security issues, we should just kill it entirely. No-one is going to be helped by a broken insecure obsolete API. - Hendrik _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
