Time for a better Version Numbering Scheme!

The traditional major.minor.patchlevel versioning scheme is no longer of real use:

• users want new features when they are ready, not when a new major version is crafted
• there is a major-version-number-increase fear in open source development, thus major version bumps sometimes come very random (see Linux for example)
• distros fire the major-version-number-increase fear because they are much more hesitant to accept new packages with increased major version

In conclusion, the major version number has become cosmetic for many projects. Take rsyslog as an example: when we switched to rsyslog scheduled releases, we also switched to just incrementing the minor version component, which now actually increments with each release - but nothing else. We still use the 8.x.0 scheme, where x is more or less the real version number. We keep that old scheme for cosmetic reasons, aka "people are used to it".

Some projects, most notably systemd, which probably invented that scheme, are more boldly: the have switched to a single ever-increasing integer as version (so you talk of e.g. version 221 vs 235 of systemd). This needs some adaption from the user side, but seems to be accepted by now.

And different other approach, known from Ubuntu, is to use "wine-versioning": just use the date. So we have 14.04, 16.04, 17.04 representing year and month of release. This also works well, but is unusual yet for single projects.

What made me think about this problem? When Jan started his log anonymizer project, we thought about how it should be versioned. We concluded that a single ever-incrementing version number is the right path to take. For this project, and most probably for all future ones. Maybe even rsyslog will at some time make the switch to a single version digit...

The post Time for a better Version Numbering Scheme! appeared first on Security Boulevard.

from Time for a better Version Numbering Scheme!