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

[minor] - working towards new stable

odd: unstable, even: stable

[increment] - updates/fixes to the base release

stable vs. development

● increasing tendency to not use dev buildso 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 listo improvements on auto-testing (testbench)

o new release/versioning scheme

o new release cycle

o inspired by projects like Chrome or Firefox

rsyslog v8.6+ release cycle

● no longer numbered dev releaseso 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 releaseso 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

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

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

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.

What is supported under this

model?

● with the old model, we supportedo the current stable

o the current devel

● that’s exactly what we do with the new

modelo 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/

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)