It's nice that they're being explicit about breaking changes, but it's still a pain that they're doing them in the first place. I understand the argument for moving quickly, but projects that use LLVM suffer as a result.<p>Basically, any code that uses LLVM bitrots very quickly because the API is (potentially) incompatible on each release. The way that large projects (like Rust [0]) generally deal with this is by sticking close to the bleeding edge of development, and have an established process for integrating changes as they come. But smaller projects just don't have the resources to do this.<p>KLEE (a symbolic execution engine) appears to be 5 versions behind the newest release [1]. Terra (a language focusing on metaprogramming for high performance) [2] is only one version behind, but the maintainer has since graduated and I'm worried the community is too small to keep it from bitrotting.<p>Nominally the C API is supposed to solve this by being more stable, but it achieves this by exposing a smaller surface area, which means you can't do a lot of what you might need to do with this API.<p>I'd like a stable, full-featured API for LLVM. It sounds like they're going this way with the bitcode format, and I think they could start to move in this direction with the API as well. When the project was young, the argument was that avoiding stability allowed the developers the flexibility to explore design decisions and make different tradeoffs over time necessary for the long-term health of the code base. I understand that. But this instability makes it essentially impossible to maintain client projects without ongoing effort, and means that small projects almost always bitrot.<p>I think we know enough now to develop a pretty decent stable API for LLVM. And I'd be a lot more confident in trusting smaller projects that use LLVM if such an API existed.<p>[0]: <a href="https://www.rust-lang.org/" rel="nofollow">https://www.rust-lang.org/</a>
[1]: <a href="https://klee.github.io/getting-started/" rel="nofollow">https://klee.github.io/getting-started/</a>
[2]: <a href="http://terralang.org/" rel="nofollow">http://terralang.org/</a>
I, for one, cannot keep track of which version we're currently at. It used to be that a major version was introduced with fanfare and broke things. The holy 1.0 or versions such as Python 3 and or Gnome 3. I will always remember if I'm running 2.x or 3.x.<p>Some time after the major version hits 3, the madness seems to begin. Am I running Firefox 73 or 85 or was that last years version? I honestly don't know anymore. Are the stable versions even, odd, Fibonacci or prime?<p>Why not be brave about it and use date-based numberings such as 16.12!
I'm glad that semver is being widely adopted outside of the npm/rails world. It's incredibly useful to understand how much work will go into upgrading a package.<p>I think the attachment around "saving" major releases are really just attachments to marketing messages of yesteryear. It still feels good to announce "Library Version 3!", but from a technical perspective, semver is far more consumable and sensible. I'd rather be confident Lib v27.3.0 -> v27.4.3 won't break my build than having v2.9.0 -> v2.10.11 break my build, but look nicer.
Postgres is going in this direction starting with the next release: <a href="http://www.databasesoup.com/2016/05/changing-postgresql-version-numbering.html" rel="nofollow">http://www.databasesoup.com/2016/05/changing-postgresql-vers...</a>
Why can't they just go with a year based version number like Ubuntu and Windows? $year.$month-$patch so LLVM 5.0 would be LLVM 17.09 (September 2017).
They still haven't got it right ; you can only decide how the version number should change by comparing the software to previously released versions. Deciding ahead of time how it will change on a periodic basis is a mistake.
So stupid. The old scheme is easy to read if you just remove the dot in your mind: 3.8 -> 38, 3.9 -> 39. Now They make it complex by 38.0 -> 38, 39.0 -> 39. Removing a dot and a zero. Not helpful and So stupid.