As we know, rsyslog uses a version number scheme of
8.<real-version>.0
where we increment <real-version> every 6 weeks with each release. The 8 and 0 are constant (well, the 0 could change to 1 with a very important patch, but in practice we have only done this once).
While this scheme has worked pretty well since we introduced it, I often see people not understanding that there is really a big difference between 8.24 and e.g. 8.40. Looking at recent trends in software versioning, we see
- single-number versions, e.g. in systemd
This is actually what we use, except that we make it look like and old-style version number by the prefix 8 and suffix 0. - date-based versions, e.g. by distros (Ubuntu 18.04)
With the next release, will will make more clear how old a version really is. To do so, we change the version number slightly to
8.yymm.0
where yy is the two-digit year and mm the two-digit month of the release date. We release every 6 weeks, so we will never have two releases within the same month.
So the next version will be 8.1901.0 instead of 8.41.0. To make things even more clear, rsyslog visible version output will be even more up to the point: rsyslog -v will now report “8.1901.0 (aka 2019.01)“. I am right now implementing these changes.
This worked out as the best scheme in a very positive mailing list discussion. For details on the decision, please have a look at that thread. In a nutshell, it has the following advantages:
- it does not break the “major version number”, so enterprise distros will hopefully continue to provide somewhat current versions of rsyslog
- the end-user is able to detect an outdated version
- if we want to do another version numbering change, we still have the “major version number” which we could increase
- patches can still be