OK, so indeed, no features in between major releases.
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.
> How can you create a stable product that targets a constantly breaking API (short of picking a version and sticking with it)?
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.
> How can you create a stable product that targets a constantly breaking API
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.
Unfortunately the assertion that you control which LLVM version you use isn't always the case. Debian 8 stable is still using LLVM 3.5, while homebrew on OSX and archlinux typically track the latest stable version (currently 3.9). Crystal, the programming language I work on, has to work on both versions and a few in between. (We're dropping support for < 3.8 soon though). Sure, we could bundle a LLVM version with the language, but that has several disadvantages, including size and extra work to build and distribute the package securely.
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]
It is my understanding that this is semi-explicit in the culture of the LLVM project as a BSD analog to the architectural damage sometimes described with GCC and GPL: instead of "we don't like supported intermediate data formats, as it allows people to hoard code: if you want to use our code you have to link to it, which will force you to open source your code so it can be upstreamed" they play "we don't like supported APIs, as it allows people to hoard code: if you want to use our code you will spend a lot of your time on the merge treadmill, which will eventually demoralize you into begging for us to upstream your code".
Honestly I just think distros and package managers are the busted ones here. LLVM is strongly coupled to your language's semantics, and I'm unaware of any good reason to force every compiler to use the same version.
This is why I wish more package managers had a (more) formalized versions of what Gentoo calls "slots". One of the major uses of slots in Gentoo is to represent major versions of libraries, s.t. LLVM 3.5 would be in the "3.5" slot, and LLVM 4 would be in the "4" slot. Dependencies are declared against slots, and the standard *nix naming convention for shared objects trivially lets multiple slots be installed at the same time.
(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.)
It's not a technical problem. All distro package managers allow for parallel-installed libraries one way or another.
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.
Just curious - why not define a macro for some of those? For example DI_FLAGS_TYPE that resolves to DINode::DIFlags / uint as needed? It seems there are some similarities that could be abstracted.
Also a cleanup could be simpler later - find/replace the macro.
But major releases are always expected to be API-breaking, right? Isn't that basically the (SemVer, at least) definition of a major vs minor release?
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...)
Major releases in SemVer can break the API, yes. But the alternative a lot of people would like, which is what SemVer contemplates, is to have a distinction between releases that add features without breaking the API, and less frequent releases that break API. For example, following this 4.0.0 release, in the SemVer model there would then be a series of 4.1.x, 4.2.x, etc. releases that add new features with backwards compatibility, followed only sometime considerably later by a 5.x.x that breaks API.
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.).
When it comes to a compiler, I think I would rather have a statically linked LLVM in the compiler than a shared object anyway, which would make this moot.
It is supposed to be "mostly" API/ABI stable at the C API level. The C++ API is always (and has always been) completely unstable. One way to address it is to have your own wrapper around LLVM that provide the feature you need, and these wrapper can retarget multiple versions of LLVM at will.
Hard to say. I'm pretty sure you can create any piece of IR (almost), and Optimize/CodeGen. We're open to add new APIs when someone needs one that is missing.
We only break the C API when there is really no choice.
For example when I removed the C++ API getGlobalContext() I made sure to preserve the equivalent C API: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-201... ; but it is not always possible.
I personally do not agree with their line of reasoning.