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