Mailing List Archive

rsyslog version numbering - was: RE: rsyslog 3.0.0 stable? - feedback, please
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

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Raoul Bhatia [IPAX]
> Sent: Tuesday, March 25, 2008 5:04 PM
> To: rsyslog-users
> Subject: Re: [rsyslog] rsyslog 3.0.0 stable? - feedback, please
>
> Rainer Gerhards wrote:
> > Hi all,
> >
> > a question on the forum
> > (http://www.rsyslog.com/PNphpBB2-viewtopic-p-1113.phtml#1113 ) and a
> bit
> > asking around finally made me think about the possibility of a v3
> stable
> > version, something that dangled on my mind for a while now... While
> it
> > is just three month since v2 stable, we have gone a long way and
> during
> > that time the new queue engine has much matured. As "development"
> state
> > is most often a show-stopper for putting code into production, I
> think
> > about releasing a 3.0.0 stable (based on the most recent 3.12.x
> version
> > WITHOUT RELP support).
> >
> >>From a support perspective, I'd like to continue support v2 stable
> and
> > obviously v3 stable and development concurrently. Development would
> > continue with 3.13.0 (RELP support), and 3.0.0 would only receive
bug
> > fixes. Some time from now, 3.<whatever>.<whatever> would become
3.1.0
> > stable. At this point, I would drop support/fixing for
3.0.<whatever>
> > and ask users with problems in the branch to update to
> 3.1.<whatever>.
>
> i guess this will cause serious headake because people tend to think
> like this:
>
> 3.0.x is less mature/was released before
> 3.1.x is less mature/was released before
> 3.12.x is less mature/was released before
> 3.13.x
>
> i guess there should be a deliberate versioning scheme. examples are:
>
> - versioning similar to the linux kernel
> - release 3.12.x as 3.12.x-stable and continue development without
this
> tag.
> - something else
>
> but i guess its no good to jump from 3.12.x back to 3.0.x and from a
> future revision such as 3.40.x back to 3.1.x
>
> cheers,
> raoul
> --
> ____________________________________________________________________
> DI (FH) Raoul Bhatia M.Sc. email. r.bhatia at ipax.at
> Technischer Leiter
>
> IPAX - Aloy Bhatia Hava OEG web. http://www.ipax.at
> Barawitzkagasse 10/2/2/11 email. office at ipax.at
> 1190 Wien tel. +43 1 3670030
> FN 277995t HG Wien fax. +43 1 3670030 15
> ____________________________________________________________________
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
rsyslog version numbering - was: RE: rsyslog 3.0.0 stable? - feedback, please [ In reply to ]
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
rsyslog version numbering - was: RE: rsyslog 3.0.0 stable? - feedback, please [ In reply to ]
Hi Peter,

thanks for the feedback. So it looks like we go for the 4-number scheme.

If I look at the migration case, I am tempted to do a one-time move to
4.0.x.x (stable) and 4.1.x.x (devel) and drop the v3 tree (flagged as
interim devel release) to prevent any confusion about version numbers.
Changing from a 3-number to a 4-number scheme within the same major
release sounds confusing in itself to me.

Any concerns with such an approach? Anyone?

Rainer

> -----Original Message-----
> From: Peter Vrabec [mailto:pvrabec at redhat.com]
> Sent: Wednesday, March 26, 2008 11:47 AM
> To: rsyslog at lists.adiscon.com
> Cc: Rainer Gerhards
> Subject: Re: [rsyslog] rsyslog version numbering - was: RE: rsyslog
> 3.0.0 stable? - feedback, please
>
> 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
rsyslog version numbering - was: RE: rsyslog 3.0.0 stable? - feedback, please [ In reply to ]
Rainer Gerhards wrote:
> Hi Peter,
>
> thanks for the feedback. So it looks like we go for the 4-number scheme.
>
> If I look at the migration case, I am tempted to do a one-time move to
> 4.0.x.x (stable) and 4.1.x.x (devel) and drop the v3 tree (flagged as
> interim devel release) to prevent any confusion about version numbers.
> Changing from a 3-number to a 4-number scheme within the same major
> release sounds confusing in itself to me.

I support the suggestion above. Trying to number within v3
is going to wreak havoc on attempts to update properly.

p.s. To be perfectly honest, I didn't think a move to
4-number was even necessary, but I think you'd know better
than anyone else what is in the pipeline for rsyslog, and if
those are major enough to require "major" number to be
changed, then, yeah, it wouldn't make sense to see 10.x.x
within a year or two.

johnn