9 ms·

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

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

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