In general, if new versions of libraries are breaking the ABI or API, the library developer needs to be thoroughly scolded. We are well capable and have the nec

In general, if new versions of libraries are breaking the ABI or API, the library developer needs to be thoroughly scolded. We are well capable and have the necessary workflows to create ABI and API stable feature releases. If vendors chose not to use these practices to create stable software, we need to criticize them and work to replace developers who don't respect their users enough not to break everything on every release. Arch, for example, has clang3.5 and clang available because 3.7 was an ABI break. It has gstreamer 0.10 and 1.0 as separate packages because it was an API break. These projects respect these design constraints and should be trustworthy, and notify downstream of breaking issues like that well in advance so packagers can avoid repackaging upgrades expecting smooth transitions. But its unfair to users and developers to use carte blanche policy of freezing everything because some bad apples cannot maintain ABI/API stability.