
LLVM's New Versioning Scheme - zmodem
http://blog.llvm.org/2016/12/llvms-new-versioning-scheme.html
======
eslaught
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.

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.

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.

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.

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.

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.

[0]: [https://www.rust-lang.org/](https://www.rust-lang.org/) [1]:
[https://klee.github.io/getting-started/](https://klee.github.io/getting-
started/) [2]: [http://terralang.org/](http://terralang.org/)

~~~
the_duke
Thank you for the only comment that isn't shallow semver debate.

And for being spot on.

LLVM is an incredible piece of software, but it's the lowest part in the
stack.

Sure, clang, rust or swift have enough manpower to always follow, but smaller
languages / compilers can't possibly hope to deal with breaking changes all
the time.

The constant breaking changes also make it very hard to support multiple LLVM
versions simultaneously.

Which makes development and deployment harder, because you can usually only
install one LLVM version via distro packages.

So if you want to compile something that depends on an older / newer LLVM
version, you have to compile LLVM, which takes a loooong time and is not
something you can bring many people to do.

~~~
sanxiyn
> The constant breaking changes also make it very hard to support multiple
> LLVM versions simultaneously.

Rust supports LLVM 3.7, 3.8, and 3.9, and it isn't particularly hard to do so.
Very annoying, yes, hard, no. It does need a bit of manpower though.

~~~
pyvpx
in open source man power is the hardest part, no?

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

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?

Why not be brave about it and use date-based numberings such as 16.12!

~~~
lilyball
I like the idea of Semantic Versioning, but it does cause problems where if
I'm going to do several breaking releases one after another I have to keep
bumping the major version, and I hate that. I've actually put off doing
breaking changes simply because I didn't want to bump the major version
number, but I don't like that either.

Thinking on it now, I wish instead of major.minor.patch the format was
major.breaking.minor.patch, where the first component is for "significant"
releases, and the second component is what you use when you're simply
introducing breaking changes (but doesn't qualify as a "significant" release).

~~~
humanrebar
> major.breaking.minor.patch

That's the same thing as projectName.major.minor.patch in some respects. You
could just rebrand the project if it's a _completely_ different direction.
There's not a technical reason to keep the name, just a
marketing/political/organizational reason.

~~~
thomaslee
Exactly. You can keep the brand while still communicating the fact it's an
overhaul.

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

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.

------
amitlan
Postgres is going in this direction starting with the next release:
[http://www.databasesoup.com/2016/05/changing-postgresql-
vers...](http://www.databasesoup.com/2016/05/changing-postgresql-version-
numbering.html)

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

~~~
richardwhiuk
Nice, introduce a bug every century when 00 > 99.

~~~
to3m
There are numbers greater than 99.

I'd like to provide some examples but I can't find my calculator :(

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

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

