[FFmpeg-devel] [libav-devel] [PATCH 0/20] removal of deprecated features

Vittorio Giovara vittorio.giovara at gmail.com
Fri Jul 31 16:17:24 CEST 2015

On Thu, Jul 30, 2015 at 6:10 PM, Andreas Cadhalpun
<andreas.cadhalpun at googlemail.com> wrote:
> Removing these APIs causes compile failures, which are more severe than
> occasional runtime failures. It means people have to use old versions of
> the libav* libraries.

I disagree as well, it's true that noone likes code failing to
compile, but a runtime misbehaviour is several orders of magnitude
worse. Also, in my opinion, if maintainers or the community don't
upgrade their code (or code they care about) when APIs change, it's
not a good sign of a healthy, engaged environment, where code can be
left bitrotting.

>> I actually did fix a huge number of packages during the last two API
>> breaks. But it's not really reasonable to expect me to do it all the
>> time.
> Certainly. But someone has to do the work, if you want to remove widely
> used APIs.

"widely used APIs" that were marked deprecated two years ago. That
someone is the downstream project maintainer.

Exactly like there is a "promise" that API won't be broken (unless
necessary) between minor releases, by using libav APIs you "agree"
that there can be breakage between major, and for good reasons too.
The "announcement" is in the form of warnings when you try to use the
API. Not removing deprecated APIs when the time is due would mean that
no deprecation would be taken seriously, thus neutering the whole
concept of deprecating code.

Also please kindly stop saying "you should do this" or "you should do
that", noone is asking you to do anything, so don't try to impose
additional expectations on libav maintainers. Finally there is still
time before distributions pick up candidates for new releases, both of
the library and of the downstream project, so I don't really see any
use of complaining now (two years *after* the deprecation was


More information about the ffmpeg-devel mailing list