On Thu, Jul 30, 2015 at 6:10 PM, Andreas Cadhalpun <andreas.cadhal...@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 announced). Cheers -- Vittorio _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
