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.
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...)