/nit Semantic versioning (or communication) failure. I would think that "stable updates" would represent minor releases (i.e. 4.x.0), not bugfix-style patches. Unless all new features will be present in major releases instead of "stable updates"?
I personally do not agree with their line of reasoning.
It's also somewhat unfortunate that, in their words, "every [six month] release is also API breaking". How can you create a stable product that targets a constantly breaking API (short of picking a version and sticking with it)?
Of course, I'm a biased, since I consider stable to be measured in years, not months; certainly not the current trend.
Nothing's forcing anyone to keep up to date, though, so anyone can pick a version and stick with it as long as they like. (So long as they keep making patches for at least the previous version for major bugs...)
However, this isn't how LLVM does things. Instead, there are pure bugfix releases (4.0.x) with no new features, followed by relatively frequent releases that both add features and break API (4.1.x, 4.2.x, etc.).
Since it's an open source library, and not a remote resource where you don't have control of what's available and deprecated items being removed, it's less of a problem. You don't have to use the newest version of LLVM if you don't want to. I'm sure at least a few prior major versions will get bug/security fixes if the problems are large enough.
That's not to say this is the correct, or best option, but it is one of the ways to go forward, and I would say it's not necessarily a bad way forward when you're still trying to build usage through innovation and features rather than retain usage. Backwards compatibility comes with its own problems, which accrue over time and can eventually strangle a project.
Perhaps in the future they will decide to use the minor version number through retaining API compatibility, and thus the major version number, for 3-4 major releases (18-24 months), while still allowing non-breaking changes to go forward. Their versioning rationale doesn't really prevent that, it's just that their current development style and goals do not support it.
That being said, the changes are typically minor, and while the bindings are a little bit too dense on {% if LibLLVM::IS_38 %} for me [0], it's certainly not hellish yet. However the LLVM debug info generator is a different story... [1]
[0] https://github.com/crystal-lang/crystal/blob/c60df09b5082918... [1] https://github.com/crystal-lang/crystal/blob/master/src/llvm...
(Other package managers tend to emulate slots by simply having multiple packages with the slot number embedded in the package name itself. Debian/Ubuntu, for example, does this, and it isn't clear to me why their scheme would preclude having multiple LLVMs installed. That said, Gentoo always seems to have difficultly with clang/llvm, so my gut wonders if there is something more at play here.)
llvm-3.4 llvm-3.5 llvm-3.6 llvm-3.7 llvm-3.8 llvm-3.9 llvm-4.0
Note that these are all package names. Each is then versioned separately - e.g. 4.0 is currently at v4.0-1, and 3.8 is at 3.8.1-18.
What's necessary for your distro to actually ship multiple versions is someone stepping up to actually maintain the thing, dealing with bug reports and monitoring security issues.
For libraries with many users that happens all the time. See the parallel packages for OpenSSL 1.0 and 1.1 in most distro repositories. For less popular libraries it's often easier to just patch all users and only ship the most recent version.
Nowadays LLVM seems firmly placed in the first camp, as patching programs to work with different LLVM versions can be a lot of work and there are quite a lot of them.
Looking into the Debian repos, you find packages for LLVM 3.7, 3.8, 3.9 and 4.0, in addition there's even a 5.0 pre-release snapshot. It's similar with Fedora and probably other distributions.
Also a cleanup could be simpler later - find/replace the macro.
You don't. This is a cost they explicitly push on consumers of the API. As a consumer, you either spend manpower to keep up-to-date, or if you don't have that luxury, you fall behind and update sporadically.
In the open source world for example, there are many volunteer driven projects that use stale versions of LLVM for exactly this reason. This causes a certain amount of churn since projects that don't maintained end up bit-rotting much more quickly than they would otherwise.
This has been the de-facto way of things with LLVM for some time, but at least they're making it explicit now.