Quoting Andreas Cadhalpun (2015-07-30 17:49:51) > On 30.07.2015 17:38, Anton Khirnov wrote: > > Quoting Andreas Cadhalpun (2015-07-30 17:05:12) > >> Ideally you should make sure that patches for all of them are available, > >> before these APIs get removed. > >> > >> Considering how widespread the use of FF_API_PIX_FMT and > >> FF_API_AVFRAME_LAVC > >> still is, it might make sense to delay their removal. > > > > Past experience indicates that if we wanted to wait for all (or even > > most) of the downstreams to adapt before breaking compatiblity, we'd > > have to wait forever. > > I think that keeping some of these APIs "forever" is much less of a problem > then breaking the majority of reverse dependencies.
The API breaks are not done for the fun of it. There's a bunch of reasons why I think keeping them is a bad idea: - some of the changes involve adding prefixes for proper namespacing, so libav does not randomly conflict with other libraries. Here, keeping the old names pretty much negates the whole point. - the less trivial changes are mostly done because the old API was inadequate. Many of the old APIs were not designed at all, but just randomly added because mplayer or ffmpeg.c happened to need some feature at the time. The result was usually un(der)documented, hard to use correctly and often not well defined in some cases. Most users of the old API that I've seen actually used it wrong and would at best occasionally fail to work, at worst crash randomly. So keeping those APIs is not really in anyone's interest IMO. - finally there's of course the maintenance burden of keeping compatibility layers, sometimes of rather large complexity. They are also often poorly tested and not very much maintained so, again, they might fail to work in some less common cases. > > > Most of then, unfortunately, have to be forced into adopting the new APIs. > > Have you tried sending them patches before breaking compatibility? > 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. -- Anton Khirnov _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
