Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
rsyslog version 
naming, v8.6.0+ 
Rainer Gerhards, rsyslog project lead
“Traditional” Scheme 
Since around v5, we used 
[major].[minor].[increment] 
[major] - changed on really big changes 
[min...
stable vs. development 
● increasing tendency to not use dev builds 
o meant little testing of new features until they bec...
rsyslog v8.6+ release cycle 
● no longer numbered dev releases 
o folks interested in new features use git master 
o in es...
This also requires a slightly new 
versioning scheme 
Looks like usual, BUT 
[major].[minor].[fixlevel] 
[major] - changed...
Note the difference in [minor] 
number 
● now it increments with each release 
● odd and even numbers don’t have special 
...
How are dev Releases identified? 
● They don’t receive an official version number 
any longer. 
● Their “version” is git’s...
What is supported under this 
model? 
● with the old model, we supported 
o the current stable 
o the current devel 
● tha...
Wrap-Up 
● rsyslog does make more granular releases 
● new features become quicker available in 
stable branches 
● auto-t...
Upcoming SlideShare
Loading in …5
×

Rsyslog version naming (v8.6.0+)

12,893 views

Published on

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

Published in: Software
  • Be the first to comment

  • Be the first to like this

Rsyslog version naming (v8.6.0+)

  1. 1. rsyslog version naming, v8.6.0+ Rainer Gerhards, rsyslog project lead
  2. 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. 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. 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. 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. 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. 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. 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. 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)

×