The new (v8.6.0+) rsyslog versioning scheme and release cycle explained.

1. rsyslog version
naming, v8.6.0+
Rainer Gerhards, rsyslog project lead

2. “Traditional” Scheme
Since around v5, we used
[major].[minor].[increment]
[major] - changed on really big changes
[minor] - working towards new stable
odd: unstable, even: stable
[increment] - updates/fixes to the base release

3. stable vs. development
● increasing tendency to not use dev builds
o meant little testing of new features until they became
stable
o so actually stable was not that stable when new
feature introduced
o dev/stable distinction had become counter-productive
● lead to discussion on rsyslog mailing list
o improvements on auto-testing (testbench)
o new release/versioning scheme
o new release cycle
o inspired by projects like Chrome or Firefox

4. rsyslog v8.6+ release cycle
● no longer numbered dev releases
o folks interested in new features use git master
o in essence, this is what already happened
o regressions tackled by more auto-testing
● more frequent stable releases
o permits to roll out new features more rapidly
o earlier feedback on new features helps to improve
them while they are still hot
o some really experimental stuff will be flagged as
such (“experimental”)
o now scheduled new release every 6 weeks
o ⇒ faster cycle helps everyone

5. This also requires a slightly new
versioning scheme
Looks like usual, BUT
[major].[minor].[fixlevel]
[major] - changed on really big changes
[minor] - counts stable branches
[fixlevel] - usually 0, except if something really
bad happens and an interim release is
required

6. Note the difference in [minor]
number
● now it increments with each release
● odd and even numbers don’t have special
semantics, all are stable
● in essence, is incremented every 6 weeks
● so… on Dec, 2nd 2014, v8.6.0 is released,
and it is scheduled to be followed by v8.7.0
on Jan, 13th 2015
● current thinking is that releases are done on
Tuesdays, with sufficient head room to the
weekend

7. How are dev Releases identified?
● They don’t receive an official version number
any longer.
● Their “version” is git’s SHA hash of the
commit in question.
● If we look at what we’ve done the past 2
years or so, only specific users really tested
new features (often implemented at their
request), and we worked with them on
exactly this “git hash basis”.
● So it’s more or less a cosmetic change.

8. What is supported under this
model?
● with the old model, we supported
o the current stable
o the current devel
● that’s exactly what we do with the new
model
o a slight exception is that “current devel” is more
precise now: it means the head of git master branch.
In practice, this was the same under the old scheme
● professional support is still available for
outdated versions: http://www.rsyslog.com/professional-services/
enterprise-support/

9. Wrap-Up
● rsyslog does make more granular releases
● new features become quicker available in
stable branches
● auto-testing has been improved (and
continuous to be) to further improve quality
● all numbered versions starting with v8.6.0
are stable
● expect new releases every 6 weeks
● expect the third version number component
to almost always be 0 (as in v8.6.0, v8.7.0)