Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×

Rsyslog version naming (v8.6.0+)

Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Wird geladen in …3
×

Hier ansehen

1 von 9 Anzeige

Weitere Verwandte Inhalte

Diashows für Sie (20)

Ähnlich wie Rsyslog version naming (v8.6.0+) (20)

Anzeige

Aktuellste (20)

Anzeige

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)

×