[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


Hi,

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 3.0.12.4
development starts with 3.1.0.0 and continues to 
3.1.0.1, 3.1.0.2, 3.1.1.0, 3.1.2.0, ... 3.1.6.10

than we decide to release stable
3.2.6.0, 3.2.6.1, 3.2.6.2
or
3.2.0.0, 3.2.0.1, 3.2.0.2?
development 3.3.0.0, ... 3.3.x.y

There is one problem 3.12.4 > 3.0.12.4 == problem with upgrade
solutions:
1) 3.12.4 -> 3.14.0.0
2) 3.12.4 -> 3.0.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