Earlier quoted context omitted.
Different versions of the same libraries for different applications is still the same problem. Fundamentally developers are writing software that distributors and integrators do not want to actually ship. There are two independent circumstances to that, though. Either the developer does not deserve downstream trust because they abuse their users by breaking their APIs, ABIs, or UX's without due notice or process. Thi…
From where i sit, what seems to block most distributors from upgrading is the rigidity of their tradition package managers when dealing with multiple versions. Thus they are reluctant to adopt new version of something, because the dependency chain may force a update of a large part of a installed system. A package manager that can handle multiple version frees them from this worry, without the admin of a system havin…
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.