[FFmpeg-devel] [libav-devel] [PATCH 0/20] removal of deprecated features
h.leppkes at gmail.com
Sat Aug 1 00:07:54 CEST 2015
On Fri, Jul 31, 2015 at 5:47 PM, Nicolas George <george at 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,
>> 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
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.
More information about the ffmpeg-devel