New Status Versioning Scheme

The usual versioning uses 2, 3, or sometimes 4 numbers, for example: 1.9.0.1

  • 1 : Major revision (new UI, lots of new features, conceptual change, breaking changes, etc.)
  • 9 : Minor revision (smaller releases, weekly, bi weekly, small sets of new features)
  • 0 : Bugfix revision, bugfixes, hotfixes, small tweaks to major or minor revisions.
  • 1 : Build number (if used). You can see that in .NET framework using something like 2.0.4.2709.

Currently we increment the so called bugfix revision number on weekly releases, so last it was 0.9.33, and next week it’s going to be 0.9.34. This versioning scheme makes no sense, and makes it harder to release hotfixes.

For example the 0.9.32 release was re-released 4 times with fixes:

All those revisions were bugfix revisions. And should have been incrementing the bugfix number. What should have happened was 0.10.0 is released, and after that 0.10.1, 0.10.2, and so on, were hotfixes to that weekly release.

So I propose from next release we start incrementing the minor revision rather than the bugfix revision. Which would make it 0.10.0, rather than 0.9.34.
Of course this change in versioning scheme would have to be communicated to the users.

7 Likes

Agree with Jakub, this versioning scheme makes much more sense.

Agree as well, the existing version scheme doesn’t capture the necessary information.

Agree, I guess somehow 0.9.xx became really-close-to 1.0 and we kept abusing the notation. Not sure why we didn’t move to 0.10 before to be honest. Let’s do it!

As part of comms for this we probably want to mention that our 0.9.xx → 0.9.xx+1 jumps were essentially 0.xx-> 0.xx+1 jumps, in order to manage expectations. cc @rachel

4 Likes

cc @jonathan as well

1 Like

Right, I kinda understand that, but in general there’s plenty of projects that do multi-digit revisions. Linux kernel is a case in point. Right now stable version is 4.20.12.

agree also! abcdedef

I consider this topic closed since we are already using this scheme.