- 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
Wednesday, October 25, 2017
Time for a better Version Numbering Scheme!
The traditional major.minor.patchlevel versioning scheme is no longer of real use:
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...
Today, we release rsyslog 8.31. This is probably one of the biggest releases in the past couple of years. While it also offers great new fu...
Did you ever use TCP to transfer syslog reliably? And do you think that makes you immune against message loss? If so, it's time to think...
As most of you know, rsyslog permits to pull multiple lines from a text file and combine these into a single message. This is done with the ...
I currently think about creating a very basic shipper for log files, but wonder if it really makes sense. I am especially concerned if good ...