Rsyslog version naming (v8.6.0+)
Download as PPTX, PDF•0 likes•13,502 views
The rsyslog project has adopted a new versioning and release cycle scheme to provide features to users more quickly while maintaining stability. The major changes are: 1) Stable releases will now occur every 6 weeks rather than distinguishing between stable and development releases. 2) The minor version number will increment with each new release rather than distinguishing between odd and even numbers. 3) Development versions are now identified by their git commit hash rather than a version number. This allows new features to reach users more rapidly without compromising stability through more frequent testing.
![“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](https://image.slidesharecdn.com/rsyslogversionnamingv8-141201110718-conversion-gate02/85/Rsyslog-version-naming-v8-6-0-2-320.jpg)
![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](https://image.slidesharecdn.com/rsyslogversionnamingv8-141201110718-conversion-gate02/85/Rsyslog-version-naming-v8-6-0-5-320.jpg)
![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](https://image.slidesharecdn.com/rsyslogversionnamingv8-141201110718-conversion-gate02/85/Rsyslog-version-naming-v8-6-0-6-320.jpg)
Rsyslog version naming (v8.6.0+)
- 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)