[rsyslog] rsyslog version numbering - was: RE: rsyslog 3.0.0 stable? - feedback, please

Peter Vrabec pvrabec at redhat.com
Wed Mar 26 11:47:21 CET 2008


politicalmajor.major.minor.patchlevel seems good to me.

politicalmajor - something great happened, like v2 and v3
major - odd, even - developer/stable release
minor - new features
patchlevel - patchlevel

so current 3.12.4 becomes
development starts with and continues to,,,, ...

than we decide to release stable,,
development, ... 3.3.x.y

There is one problem 3.12.4 > == problem with upgrade
1) 3.12.4 ->
2) 3.12.4 -> and I'll start new epoch of rsyslog package
(Epoch: 2 in specfile, don't know how is it in other distros)

On Tuesday 25 March 2008 06:16:05 pm Rainer Gerhards wrote:
> Hi all,
> I have thought about the version numbering. Obviously, the old scheme
> (http://www.rsyslog.com/doc-version_naming.html ) is confusing and
> should be dropped.
> Rsyslog currently follows a three-number version scheme:
> major.minor.patchlevel
> I can follow an odd/even scheme on major for unstable/stable branches.
> However, with major features being continuously introduced may bring us
> to rsyslog 10.x.x by the end of the year. While I have no hard concerns,
> it seems to be unusual for open source to increase the major version
> that fast. On the other hand, I need minor.patchlevel to handle the
> smaller fixes and new major feature. I increase minor for each new
> feature (like queue engine, expression-based filters, relp, to name a
> few actual ones) and increase patchlevel for smaller changes. The three
> number scheme works well, but, again, keeps the major number very
> quickly growing given the current fast pace of development.
> An alternative would be to use
> politicalmajor.major.minor.patchlevel
> Where politicalmajor would only be incremented every now and then and
> actually without much technical reasoning for doing so - only then when
> we "feel" it is time for a new major release. It would probably turn out
> to be incremented around once a year, just to keep the corporate folks
> happy and the major version number reasonable low.
> Question now: which scheme should I follow? Is there any other one? If
> so, why should I follow that other scheme?
> I would appreciate quick feedback, as I'd like to settle this issue
> before releasing RELP support, which currently looks like some time
> (very) early April.
> Thanks,
> Rainer

More information about the rsyslog mailing list