10 ms·

LLVM's New Versioning Scheme

101 points by zmodem 10y ago

static_noise 10y ago
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!
- nitroll 10y ago
  I totally agree. When you release bi-annually anyway, dont really care about how much breakage a Major release introduces, totally ignore minor versions and with patch versions being more or less insignificant, why not just go with $year.$month
  - abakus 10y ago
    Or $year.A and $year.B
- deleted 10y ago
  [deleted]
- lilyball 10y ago
  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 10y ago
    > 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 10y ago
      Exactly. You can keep the brand while still communicating the fact it's an overhaul.
    - eridius 10y ago
      A significant release does not mean it's a completely different direction. It just means that it's significant in some sense.
  - cbdfghh 10y ago
    > 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. When you're doing backend/API things (where breaking changes matter), I sure hope you think a million times before making breaking changes. Can you imagine if someone had to go through millions of lines of his code to make sure nothing broke, then, a week later, you broke his code again?
    - thomaslee 10y ago
      I'm not the parent, but I sort of like the idea at first glance. I mean, it's a fine line: if I have "v1.0.0" and I break one API in one module, I'm compelled to release "v2.0.0" even though v2.0.0 is otherwise entirely compatible with v1 -- it's not as big of an upgrade as the version numbering system would imply. But if I go and drastically change things in a way likely to impact many users, that gets a brand new version number too. So v1.0.0 -> v2.0.0 only really communicates "something might break". The scheme proposed by the parent would be able to communicate "expect many things to break because I refactored the heck out of stuff to fix some long-standing design deficiencies" -- though admittedly when to bump that first version number is likely to be a subjective topic. :) Perhaps this isn't as valuable as it seems at a first glance, but if anybody's tried something like this I for one would be interested to hear about it.
- Karliss 10y ago
  >Are the stable versions even, odd, Fibonacci or prime? In case of Firefox every seventh (v%7=3) receives extended support releases.
- oconnor0 10y ago
  Every release of LLVM breaks the internal APIs. So, yes, changing the major version every release is honest and adopting semantic versioning.
  - jxy 10y ago
    Keeping up with the LLVM internal API is really a pain with the six month cycle. Is there a plan to stabilize it in the near future? I can see some open source project start to really drag, julia is still on llvm 3.7, so does ghc 8.0.1. I don't think it's healthy.
    - oconnor0 10y ago
      I believe that stability of the internal C++ APIs is a complete non-goal of LLVM/Clang.
    - KenoFischer 10y ago
      I should also note that the internal APIs are not the problem for Julia. We usually pick those up immediately. Rather, doing validation for a new release on all platforms, reducing, filing, fixing any regressions, etc is what takes the time (in addition to only a few of us knowing LLVM well enough to do so).
    - wyldfire 10y ago
      Some folks in the commercial world pull all the commits from upstream all the time in order to not fall too far behind. It's a pay-me-now-or-pay-me-later kinda thing. Forces you to take the interface breakage seriously lest it cause other commits to queue up while you let it linger.
- usrusr 10y ago
  Fully agree. Staring at the same leading number in the versions of a given piece of software for my whole life is a very acceptable worst case price to pay for opening up the version space to those really big "spiritual successor" kind of changes. Just imagine the headache if Angular had bumped the most significant number for every change pre-Angular2. All the we difference between 1.x and 2.x would be perfectly obscured.
  - usrusr 10y ago
    PS: oh, i guess i missed this, the next major angular overhaul will have to come with a full rebranding: http://angularjs.blogspot.de/2016/12/ok-let-me-explain-its-going-to-be.html http://angularjs.blogspot.de/2016/12/ok-let-me-explain-its-g...
- roboguy12 10y ago
  > Why not be brave about it and use date-based numberings Like IntelliJ IDEA? The version I'm running right now is 2016.3.1
- songco 10y ago
  I prefer versions like 16.12 or 2016.12...
satysin 10y ago
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 10y ago
  Nice, introduce a bug every century when 00 > 99.
  - to3m 10y ago
    There are numbers greater than 99. I'd like to provide some examples but I can't find my calculator :(
  - user5994461 10y ago
    They can just upgrade from 99.12 to 2100.01
  - flukus 10y ago
    That's someone else's problem. And realistically for most/all software today, never going to be a real problem. Or avoid it entirely and use a 4 digit year.
  - satysin 10y ago
    No you don't, it isn't an internal data type like Y2K. You just go from (20)99 to (2)100 to (2)101 ...
- slacka 10y ago
  As the article stated, LLVM 5.0 should really be called LLVM 5, and isn't it easier to remember and write than 17.09. And IF you do care about the patch level, then it's LLVM 5.1 vs 17.09.1, again I'll take 5.1 any day.
wuxb 10y ago
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.
nemothekid 10y ago
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.
hossbeast 10y ago
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.
eslaught 10y ago
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 10y ago
  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.
amitlan 10y ago
Postgres is going in this direction starting with the next release: http://www.databasesoup.com/2016/05/changing-postgresql-version-numbering.html http://www.databasesoup.com/2016/05/changing-postgresql-vers...

101 points by zmodem 10y ago

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!

nitroll 10y ago
I totally agree. When you release bi-annually anyway, dont really care about how much breakage a Major release introduces, totally ignore minor versions and with patch versions being more or less insignificant, why not just go with $year.$month
- abakus 10y ago
  Or $year.A and $year.B
deleted 10y ago
[deleted]
lilyball 10y ago
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 10y ago
  > 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 10y ago
    Exactly. You can keep the brand while still communicating the fact it's an overhaul.
  - eridius 10y ago
    A significant release does not mean it's a completely different direction. It just means that it's significant in some sense.
- cbdfghh 10y ago
  > 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. When you're doing backend/API things (where breaking changes matter), I sure hope you think a million times before making breaking changes. Can you imagine if someone had to go through millions of lines of his code to make sure nothing broke, then, a week later, you broke his code again?
  - thomaslee 10y ago
    I'm not the parent, but I sort of like the idea at first glance. I mean, it's a fine line: if I have "v1.0.0" and I break one API in one module, I'm compelled to release "v2.0.0" even though v2.0.0 is otherwise entirely compatible with v1 -- it's not as big of an upgrade as the version numbering system would imply. But if I go and drastically change things in a way likely to impact many users, that gets a brand new version number too. So v1.0.0 -> v2.0.0 only really communicates "something might break". The scheme proposed by the parent would be able to communicate "expect many things to break because I refactored the heck out of stuff to fix some long-standing design deficiencies" -- though admittedly when to bump that first version number is likely to be a subjective topic. :) Perhaps this isn't as valuable as it seems at a first glance, but if anybody's tried something like this I for one would be interested to hear about it.
Karliss 10y ago
>Are the stable versions even, odd, Fibonacci or prime? In case of Firefox every seventh (v%7=3) receives extended support releases.
oconnor0 10y ago
Every release of LLVM breaks the internal APIs. So, yes, changing the major version every release is honest and adopting semantic versioning.
- jxy 10y ago
  Keeping up with the LLVM internal API is really a pain with the six month cycle. Is there a plan to stabilize it in the near future? I can see some open source project start to really drag, julia is still on llvm 3.7, so does ghc 8.0.1. I don't think it's healthy.
  - oconnor0 10y ago
    I believe that stability of the internal C++ APIs is a complete non-goal of LLVM/Clang.
  - KenoFischer 10y ago
    I should also note that the internal APIs are not the problem for Julia. We usually pick those up immediately. Rather, doing validation for a new release on all platforms, reducing, filing, fixing any regressions, etc is what takes the time (in addition to only a few of us knowing LLVM well enough to do so).
  - wyldfire 10y ago
    Some folks in the commercial world pull all the commits from upstream all the time in order to not fall too far behind. It's a pay-me-now-or-pay-me-later kinda thing. Forces you to take the interface breakage seriously lest it cause other commits to queue up while you let it linger.
usrusr 10y ago
Fully agree. Staring at the same leading number in the versions of a given piece of software for my whole life is a very acceptable worst case price to pay for opening up the version space to those really big "spiritual successor" kind of changes. Just imagine the headache if Angular had bumped the most significant number for every change pre-Angular2. All the we difference between 1.x and 2.x would be perfectly obscured.
- usrusr 10y ago
  PS: oh, i guess i missed this, the next major angular overhaul will have to come with a full rebranding: http://angularjs.blogspot.de/2016/12/ok-let-me-explain-its-going-to-be.html http://angularjs.blogspot.de/2016/12/ok-let-me-explain-its-g...
roboguy12 10y ago
> Why not be brave about it and use date-based numberings Like IntelliJ IDEA? The version I'm running right now is 2016.3.1
songco 10y ago
I prefer versions like 16.12 or 2016.12...

satysin 10y ago

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 10y ago
Nice, introduce a bug every century when 00 > 99.
- to3m 10y ago
  There are numbers greater than 99. I'd like to provide some examples but I can't find my calculator :(
- user5994461 10y ago
  They can just upgrade from 99.12 to 2100.01
- flukus 10y ago
  That's someone else's problem. And realistically for most/all software today, never going to be a real problem. Or avoid it entirely and use a 4 digit year.
- satysin 10y ago
  No you don't, it isn't an internal data type like Y2K. You just go from (20)99 to (2)100 to (2)101 ...
slacka 10y ago
As the article stated, LLVM 5.0 should really be called LLVM 5, and isn't it easier to remember and write than 17.09. And IF you do care about the patch level, then it's LLVM 5.1 vs 17.09.1, again I'll take 5.1 any day.

wuxb 10y ago

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.

nemothekid 10y ago

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.

hossbeast 10y ago

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.

eslaught 10y ago

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 10y ago
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.

amitlan 10y ago

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