Mailing List Archive

Hi,

> 3.13.6 stable
> 3.14.0-dev7 (relp)
> 3.15.0-dev4 (relp/tcp)
>
> Once relp is stable, we have
>
> 3.13.6 deprecated
> 3.14.0 stable relp
> 3.15.0-dev4 (relp/tcp)

There is a great disadvatage of this scheme.
3.14.0-dev7 > 3.14.0, BUT 3.14.0 is newer.

Rainer Gerhards wrote:
> So basically the "Sunday scheme" without -mf/-rc but instead just -dev.
> I guess the scheme was good for all, but the -mf/-rc was deemed

Since many folks are already familiar with alpha, beta, and
rc, I think it'd be good to stick with those as much as
possible.


> confusing. In the sample, it would look like:
> 3.13.5 stable
> 3.14.0-dev6 (relp)
> 3.15.0-dev3 (relp/tcp)

3.13.5 stable
3.14.0-beta6 (relp)
3.15.0-alpha3 (relp/tcp)


> Now let's assume I add a bugfix for the core engine. Would that bring us
> to
>
> 3.13.6 stable
> 3.14.0-dev7 (relp)
> 3.15.0-dev4 (relp/tcp)

3.13.6 stable
3.14.0-beta7 (relp)
3.15.0-alpha4 (relp/tcp)


> Once relp is stable, we have
>
> 3.13.6 deprecated
> 3.14.0 stable relp
> 3.15.0-dev4 (relp/tcp)

3.13.6 deprecated
3.14.0-rc1 (?) relp becoming stable
3.15.0-alpha4 (relp/tcp)


> TLS begun:
> 3.13.6 deprecated
> 3.14.0 stable relp
> 3.15.0-dev4 (relp/tcp)
> 3.16.0-dev0 (tls)

3.13.6 deprecated
3.14.0 stable relp
3.15.0-beta1 (relp/tcp) (3.15 now becomes beta)
3.16.0-alpha1 (tls) (the new alpha/dev branch)

In a nutshell:

alpha - very (b)leading edge dev release branch

beta - dev branch that has been out for awhile but still
being worked on

rc - the beta/dev branch finally getting ready to be
declared stable, pretty much bug-fix-only at this point

stable

deprecated

Rainer Gerhards wrote:
> This has some subtleties for me, too (well, maybe its not really
> subtleties but simply frightening me ;)). Let me try to get this back to
> a simple path. How about a simple
>
> major.minor.patchlevel-dev<devlevel>
>
> So basically the "Sunday scheme" without -mf/-rc but instead just -dev.
> I guess the scheme was good for all, but the -mf/-rc was deemed
> confusing. In the sample, it would look like:
>
> 3.13.5 stable
> 3.14.0-dev6 (relp)
> 3.15.0-dev3 (relp/tcp)

what i'm not getting is, that you
a) want to maintain some work-in-progress-patches as seperate trees.
what happens if you want to implement feature-x (ssl/tls) first
(which would then be 3.17.0) and this becomes stable faster than
relp/other stuff?

then we have
3.13.5
3.14.0-devX
3.15.0-devY
3.16.0 stable

uhm ... ?

what happens if a patch will be unstable for ages as it was some kind of
paid-for-feature but time ran out? or if a feature becomes obsolete
because of another feature?

b) why do you want to stick to some in-between-version - especially with
the v3.x scheme

which i still see as progressing as 3.14.0, 3.15.0,
3.16.0 as in the old-style so nobody is confused. therefore i call
3.14.0 3.15.0 etc. in-betwee-versions, if 3.16 is under development)


mhm, now an idea begins to take hold of me ;)

do you want to totally switch to the new scheme now? or do you want to
keep some kind of legacy numbering for v3?

maybe my problem is, that i somehow see the versioning this way:

v3.pl or rather v3.subminor.pl and
v4.minor.pl or rather v4.minor.subminor.pl (such as we can see with
kernel v2.6.24.4)

so 3.15.0 is translated to 3.0.15 in my mind. so the next step would be
3.0.16 which would become 3.16.x in the "old" release style.

perhaps you can enlighten me/us? :)

and maybe, if you want to switch to the final version scheme, we should
jump over a couple of releases and start with 3.20.0 to make things
clear?

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
____________________________________________________________________

Peter,

Ah, so you compare the strings... makes sense. But also makes clear we
have a problem with any such scheme...

... that means it applies to Johnn's suggestion, too :(

Next try, back to odd/even. So any odd version number is unstable, any
even one is stable. Once something gets stable, it is incremented to the
even version. -rc and similar things may (may!) be added to alert users.

Again into the sample case:

3.14.0 stable
3.15.6 unstable (relp)
3.17.2 unstable (relp/tcp)


Now let's assume I add a bugfix for the core engine. Would that bring us
to

3.14.1 stable
3.15.7 unstable (relp)
3.17.3 unstable (relp/tcp)

Once relp is stable, we have

3.14.1 deprecated
3.16.0 stable (relp)
3.17.3 unstable (relp/tcp)

TLS begins:
3.14.1 deprecated
3.16.0 stable (relp)
3.17.3 unstable (relp/tcp)
3.19.0 unstable (tls)

Now tcp becomes stable:

3.14.1 deprecated
3.16.0 deprecated
3.18.0 stable (relp/tcp)
3.19.0 unstable (tls)

In all cases stable > devel, at least as far as the some feature set is
concerned. There may be gaps in the minor version numbers when versions
are not yet stable.

Does that work?

Rainer

> -----Original Message-----
> From: Peter Vrabec [mailto:pvrabec at redhat.com]
> Sent: Monday, March 31, 2008 4:51 PM
> To: rsyslog at lists.adiscon.com
> Cc: Rainer Gerhards
> Subject: Re: [rsyslog] rsyslog version numbering
>
> Hi,
>
> > 3.13.6 stable
> > 3.14.0-dev7 (relp)
> > 3.15.0-dev4 (relp/tcp)
> >
> > Once relp is stable, we have
> >
> > 3.13.6 deprecated
> > 3.14.0 stable relp
> > 3.15.0-dev4 (relp/tcp)
>
> There is a great disadvatage of this scheme.
> 3.14.0-dev7 > 3.14.0, BUT 3.14.0 is newer.

Rainer Gerhards wrote:
> Peter,
>
> Ah, so you compare the strings... makes sense. But also makes clear we
> have a problem with any such scheme...
>
> ... that means it applies to Johnn's suggestion, too :(

No, I made a mistake of keeping the numbering when my main
point was more about, if you are going to use appendages, to
stick with the well-known ones (pre, alpha, beta, rc,
stable, patch).

It should work with *any* numbering scheme (yours,
Michael's, the even/odd, etc.).


The value-added benefit is it gives people an instant
knowledge of where the branch stands.

My company doesn't mind using rc's in production if we
absolutely need the features it provides. But using an alpha
would be much harder to justify.

Granted, in the end, these are somewhat all arbitrary (even
declaring something stable). But I think, like you said,
most devs (or the communities that surround a project) have
a general sense that the passage of time and what actually
gets added (bug-fix-only, etc.) to a branch help determine
these labels. That's generally good enough for most people
who end up using the software.

johnn

I couldn't agree more. I have a maturity matrix on my mind. I guess I'll
do a sample of it. Maybe that helps find a solution. The core thing is
that with a truly modular design like we have in rsyslog nothing is
stable or unstable per se. Some components are extremely stable, while
others are bleeding edge. As long as you don't use the bleeding edge
ones (and they did not touch core features) the last ironed-out alpha
devel version is rock solid.

Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Johnny Tan
> Sent: Monday, March 31, 2008 5:21 PM
> To: rsyslog-users
> Subject: Re: [rsyslog] rsyslog version numbering
>
> Rainer Gerhards wrote:
> > Peter,
> >
> > Ah, so you compare the strings... makes sense. But also makes clear
> we
> > have a problem with any such scheme...
> >
> > ... that means it applies to Johnn's suggestion, too :(
>
> No, I made a mistake of keeping the numbering when my main
> point was more about, if you are going to use appendages, to
> stick with the well-known ones (pre, alpha, beta, rc,
> stable, patch).
>
> It should work with *any* numbering scheme (yours,
> Michael's, the even/odd, etc.).
>
>
> The value-added benefit is it gives people an instant
> knowledge of where the branch stands.
>
> My company doesn't mind using rc's in production if we
> absolutely need the features it provides. But using an alpha
> would be much harder to justify.
>
> Granted, in the end, these are somewhat all arbitrary (even
> declaring something stable). But I think, like you said,
> most devs (or the communities that surround a project) have
> a general sense that the passage of time and what actually
> gets added (bug-fix-only, etc.) to a branch help determine
> these labels. That's generally good enough for most people
> who end up using the software.
>
> johnn
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog

Well... First thing is that I have urgent need to release -- there are a
couple of things in the queue. If I don't release them this week, I'll
probably don't have a chance to get to a stable any time soon. So I will
release, even at the price that the version number scheme may be less
than optimum this time.

But now on to the real meat (and thanks for sticking around on this
topic! ;))...

> Rainer Gerhards wrote:
> > This has some subtleties for me, too (well, maybe its not really
> > subtleties but simply frightening me ;)). Let me try to get this
back
> to
> > a simple path. How about a simple
> >
> > major.minor.patchlevel-dev<devlevel>
> >
> > So basically the "Sunday scheme" without -mf/-rc but instead just -
> dev.
> > I guess the scheme was good for all, but the -mf/-rc was deemed
> > confusing. In the sample, it would look like:
> >
> > 3.13.5 stable
> > 3.14.0-dev6 (relp)
> > 3.15.0-dev3 (relp/tcp)
>
> what i'm not getting is, that you
> a) want to maintain some work-in-progress-patches as seperate trees.
> what happens if you want to implement feature-x (ssl/tls) first
> (which would then be 3.17.0) and this becomes stable faster than
> relp/other stuff?
>
> then we have
> 3.13.5
> 3.14.0-devX
> 3.15.0-devY
> 3.16.0 stable
>
> uhm ... ?

[.I am answering this in the context of the version numbers above. After
Peter's note on the strcmp() of version numbers, I think that we need to
use something like odd/even where stable is compares always greater than
unstable.]

In this case, there will never be a 3.14 and 3.15 stable. This scenario
may happen. In my current scheme, we'd probably never seen a 3.11 stable
(queue engine) but a 3.12, because the queue engine needed much more
time to mature.

> what happens if a patch will be unstable for ages as it was some kind
> of
> paid-for-feature but time ran out? or if a feature becomes obsolete
> because of another feature?

Maybe the problem is that I am NOT branching off for new features. I
branch off stable releases. I fear that branching of for new features
will be much more time consuming at the current pace of development and
has high potential for conflict. Maybe I am wrong ;)

To the cases above: the paid-for-feature would never be released. That
case is not fully thought out as I did not yet find someone who want's
to pay. My perception may change when this happens ;) If a feature that
is not yet stable is obsoleted, that version will never become stable
(gap in release history).
>
> b) why do you want to stick to some in-between-version - especially
> with
> the v3.x scheme
>
> which i still see as progressing as 3.14.0, 3.15.0,
> 3.16.0 as in the old-style so nobody is confused. therefore i call
> 3.14.0 3.15.0 etc. in-betwee-versions, if 3.16 is under development)

I have a major release focus for v3: full modularization. Not reached
yet ;) Of course, that can be sacrificed. But as long as we experiment
(and we seem to do), I prefer to do that in v3 instead of risking to
lose v4, too (when we go to something else) ;)

>
> mhm, now an idea begins to take hold of me ;)
>
> do you want to totally switch to the new scheme now? or do you want to
> keep some kind of legacy numbering for v3?
>
> maybe my problem is, that i somehow see the versioning this way:
>
> v3.pl or rather v3.subminor.pl and
> v4.minor.pl or rather v4.minor.subminor.pl (such as we can see with
> kernel v2.6.24.4)
>
> so 3.15.0 is translated to 3.0.15 in my mind. so the next step would
be
> 3.0.16 which would become 3.16.x in the "old" release style.
>
> perhaps you can enlighten me/us? :)

Well, *if* I'd taken proper stable branchpoints, we would now probably
be at 3.3 or 3.4 speaking stable-wise (3.0 intial release and input
plugins, 3.1 queue (probably never delivered), 3.2 expression support,
...).

So far, rsyslog did a stable release once every 12 to 24 month. From
there on, everything was experimental. We can keep with that scheme
(less work for me), but the drawback is that it takes an immense amount
of time before those looking for stable can find new features. IMHO this
hasn't worked out well.

>
> and maybe, if you want to switch to the final version scheme, we
should
> jump over a couple of releases and start with 3.20.0 to make things
> clear?

I agree, maybe even v4 - but then the version scheme itself must have
reached stable state ;)

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

Rainer Gerhards wrote:
> confusing. In the sample, it would look like:
>
> 3.13.5 stable
> 3.14.0-dev6 (relp)
> 3.15.0-dev3 (relp/tcp)

Ok, let me take one last swipe at this, with numbering AND
labels:

3.13.5 stable
3.14.6-beta
3.15.3-alpha


>
> Now let's assume I add a bugfix for the core engine. Would that bring us
> to
>
> 3.13.6 stable
> 3.14.0-dev7 (relp)
> 3.15.0-dev4 (relp/tcp)

3.13.6 stable
3.14.7-beta
3.15.4-alpha


> Once relp is stable, we have
>
> 3.13.6 deprecated
> 3.14.0 stable relp
> 3.15.0-dev4 (relp/tcp)

3.13.6 stable
3.14.8-rc
3.15.5-alpha


> TLS begun:
> 3.13.6 deprecated
> 3.14.0 stable relp
> 3.15.0-dev4 (relp/tcp)
> 3.16.0-dev0 (tls)

3.13.6 deprecated
3.14.9 stable
3.15.5-beta
3.16.0-alpha


> Now tcp becomes stable:
>
> 3.13.6 deprecated
> 3.14.0 deprecated
> 3.15.0 stable (relp/tcp)
> 3.16.0-dev0 (tls)

Well, this is kind of a big jump, but assuming it goes
through all the proper alpha/beta/rc phases:

3.13.6 deprecated
3.14.9 deprecated
3.15.6 stable
3.16.1-alpha

So, you increment the patchlevels, as you've been doing, but
you use -alpha, -beta, -rc (with no numbers) to designate
the newness/readiness of the branch.

Please have a look at:

http://www.rsyslog.com/doc-maturity.html

It's not complete yet, because it requires some work. If it is done
parallel to the releases, it's not much work. I personally would find
this much more useful than a single binary switch for all of the modules
(which never is really right ;)). That, of course, doesn't solve the
version numbering question ;)

Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Johnny Tan
> Sent: Monday, March 31, 2008 5:45 PM
> To: rsyslog-users
> Subject: Re: [rsyslog] rsyslog version numbering
>
> Rainer Gerhards wrote:
> > confusing. In the sample, it would look like:
> >
> > 3.13.5 stable
> > 3.14.0-dev6 (relp)
> > 3.15.0-dev3 (relp/tcp)
>
> Ok, let me take one last swipe at this, with numbering AND
> labels:
>
> 3.13.5 stable
> 3.14.6-beta
> 3.15.3-alpha
>
>
> >
> > Now let's assume I add a bugfix for the core engine. Would that
bring
> us
> > to
> >
> > 3.13.6 stable
> > 3.14.0-dev7 (relp)
> > 3.15.0-dev4 (relp/tcp)
>
> 3.13.6 stable
> 3.14.7-beta
> 3.15.4-alpha
>
>
> > Once relp is stable, we have
> >
> > 3.13.6 deprecated
> > 3.14.0 stable relp
> > 3.15.0-dev4 (relp/tcp)
>
> 3.13.6 stable
> 3.14.8-rc
> 3.15.5-alpha
>
>
> > TLS begun:
> > 3.13.6 deprecated
> > 3.14.0 stable relp
> > 3.15.0-dev4 (relp/tcp)
> > 3.16.0-dev0 (tls)
>
> 3.13.6 deprecated
> 3.14.9 stable
> 3.15.5-beta
> 3.16.0-alpha
>
>
> > Now tcp becomes stable:
> >
> > 3.13.6 deprecated
> > 3.14.0 deprecated
> > 3.15.0 stable (relp/tcp)
> > 3.16.0-dev0 (tls)
>
> Well, this is kind of a big jump, but assuming it goes
> through all the proper alpha/beta/rc phases:
>
> 3.13.6 deprecated
> 3.14.9 deprecated
> 3.15.6 stable
> 3.16.1-alpha
>
> So, you increment the patchlevels, as you've been doing, but
> you use -alpha, -beta, -rc (with no numbers) to designate
> the newness/readiness of the branch.
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog

Rainer Gerhards wrote:
> Please have a look at:
>
> http://www.rsyslog.com/doc-maturity.html
>
> It's not complete yet, because it requires some work. If it is done
> parallel to the releases, it's not much work. I personally would find
> this much more useful than a single binary switch for all of the modules
> (which never is really right ;)). That, of course, doesn't solve the
> version numbering question ;)

as a short input if you want to provide a feature matrix:

http://linux-vserver.org/Feature_Matrix

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
____________________________________________________________________

2008/3/31, Rainer Gerhards <rgerhards at hq.adiscon.com>:
> Well... First thing is that I have urgent need to release -- there are a
> couple of things in the queue. If I don't release them this week, I'll
> probably don't have a chance to get to a stable any time soon. So I will
> release, even at the price that the version number scheme may be less
> than optimum this time.
>
> But now on to the real meat (and thanks for sticking around on this
> topic! ;))...

I like the idea of the odd/even numbering (of the minor number) to
distinguish unstable/stable release. E.g. GNOME uses it and it seems
to work fine for them.

E.g. the latest stable release was 2.22.0 (and minor point/bug fix
releases usually follow as 2.22.1, 2.22.2...)
The major development is going on in 2.23.
The first unstable release will be 2.23.1, followed by 2.23.2, 2.23.3,...
As soon as the code base stabilises (reaching beta/rc quality), they
will release
2.23.90,2.23.91,... and the final stable release will be 2.24.0.
(no -pre,-alpha, -beta suffixes, only numbers, which are ordered correctly).


Cheers,
Michael

--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

Michael Biebl wrote:
> I like the idea of the odd/even numbering (of the minor number) to
> distinguish unstable/stable release. E.g. GNOME uses it and it seems
> to work fine for them.
>
> E.g. the latest stable release was 2.22.0 (and minor point/bug fix
> releases usually follow as 2.22.1, 2.22.2...)
> The major development is going on in 2.23.
> The first unstable release will be 2.23.1, followed by 2.23.2, 2.23.3,...
> As soon as the code base stabilises (reaching beta/rc quality), they
> will release
> 2.23.90,2.23.91,... and the final stable release will be 2.24.0.
> (no -pre,-alpha, -beta suffixes, only numbers, which are ordered correctly).

its not new as afairc the linux kernel established this scheme.

anyways, what bugs me is, that we then will have something like:

3.20.x - stable
3.21.x - unstable relp
no 3.22.x
3.23.x - unstable tls

when we then decide to implement yet-another-new-feature-in-a-
seperate-tree, we will end up with a scenario like

3.20.x - oldstable
3.21.x - unstable relp - closed
3.23.x - unstable tls
3.25.x - unstable featureX
3.26.x - stable

or similar.

that is kind of odd ...

rainer: what do you think about only having one dev tree and
having some patchsets for not-that-much-worked-on features
(e.g. tls, featureX). of course, you can arrange your repository as
you wish, but i would stick to *one* stable version and *one* dev
version for the testers.

everything else should be build (as patches) on top of these 2 branches.
as a nice effect, we will have only 1 stable core and 1 dev core and
have no issues when it comes to merging core-relp with core-tls with
core-featureX.

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
____________________________________________________________________

2008/4/4, Raoul Bhatia [IPAX] <r.bhatia at ipax.at>:
> Michael Biebl wrote:
> > I like the idea of the odd/even numbering (of the minor number) to
> > distinguish unstable/stable release. E.g. GNOME uses it and it seems
> > to work fine for them.
> >
> > E.g. the latest stable release was 2.22.0 (and minor point/bug fix
> > releases usually follow as 2.22.1, 2.22.2...)
> > The major development is going on in 2.23.
> > The first unstable release will be 2.23.1, followed by 2.23.2, 2.23.3,...
> > As soon as the code base stabilises (reaching beta/rc quality), they
> > will release
> > 2.23.90,2.23.91,... and the final stable release will be 2.24.0.
> > (no -pre,-alpha, -beta suffixes, only numbers, which are ordered correctly).
>
>
> its not new as afairc the linux kernel established this scheme.
>
> anyways, what bugs me is, that we then will have something like:
>
> 3.20.x - stable
> 3.21.x - unstable relp
> no 3.22.x
> 3.23.x - unstable tls
>
> when we then decide to implement yet-another-new-feature-in-a-
> seperate-tree, we will end up with a scenario like
>
> 3.20.x - oldstable
> 3.21.x - unstable relp - closed
> 3.23.x - unstable tls
> 3.25.x - unstable featureX
> 3.26.x - stable
>
> or similar.
>
> that is kind of odd ...
>

git feature branches would be ideal for this kind of development imho.

> rainer: what do you think about only having one dev tree and
> having some patchsets for not-that-much-worked-on features
> (e.g. tls, featureX). of course, you can arrange your repository as
> you wish, but i would stick to *one* stable version and *one* dev
> version for the testers.
>
> everything else should be build (as patches) on top of these 2 branches.
> as a nice effect, we will have only 1 stable core and 1 dev core and
> have no issues when it comes to merging core-relp with core-tls with
> core-featureX.

It would definitely make it easier if there was only one stable and
one development tree (and maybe a third one, oldstable).
Rainer could work on experimental new features in separate git feature
branches and when he considers them ready for testing, merge them into
the dev branch (usually called master in git). E.g. the relp
functionality could be in a branch called feature-relp, tls in
feature-tls etc.

Cheers,
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

Ah, the source of the misunderstanding finally hits me...

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Raoul Bhatia [IPAX]
> Sent: Friday, April 04, 2008 10:16 AM
> To: rsyslog-users
> Subject: Re: [rsyslog] rsyslog version numbering
>
> Michael Biebl wrote:
> > I like the idea of the odd/even numbering (of the minor number) to
> > distinguish unstable/stable release. E.g. GNOME uses it and it seems
> > to work fine for them.
> >
> > E.g. the latest stable release was 2.22.0 (and minor point/bug fix
> > releases usually follow as 2.22.1, 2.22.2...)
> > The major development is going on in 2.23.
> > The first unstable release will be 2.23.1, followed by 2.23.2,
> 2.23.3,...
> > As soon as the code base stabilises (reaching beta/rc quality), they
> > will release
> > 2.23.90,2.23.91,... and the final stable release will be 2.24.0.
> > (no -pre,-alpha, -beta suffixes, only numbers, which are ordered
> correctly).
>
> its not new as afairc the linux kernel established this scheme.
>
> anyways, what bugs me is, that we then will have something like:
>
> 3.20.x - stable
> 3.21.x - unstable relp
> no 3.22.x
> 3.23.x - unstable tls
>
> when we then decide to implement yet-another-new-feature-in-a-
> seperate-tree, we will end up with a scenario like

The trees are NOT independent of each other! There is always just one
development tree. In the above scenario, 3.23.x *includes* 3.21.x. Let's
look what I currently try:

We will finally see 3.14.0 stable today. I have also done a number of
improvements since the relp version. So I have (not yet released)

3.14.0 - stable, bug fixes only
3.15.0 - everything that is in stable, plus relp - set to stabilize, bug
fixes only
3.17.0 - everything that is in 3.15.x (note the .x not .0) plus new
features - devel

Development only happens in 3.17.0. When a feature focus has been
reached, I now plan to branch off that release and let it stabilize
(that is no new features, just bug fixes). I am trialing this currently
with the 3.15.x branch. So far, it looks manageable. The plan is to
slowly migrate 3.15.x to become 3.16.0, the next stable, deprecating
3.14.x when it comes out. I think that'll on average will be every two
month, but I don't know yet. With 3.15.x it may be quicker, as the whole
RELP code is in an external library and thus the core engine has not
been destabilized.

>
> 3.20.x - oldstable
> 3.21.x - unstable relp - closed
> 3.23.x - unstable tls
> 3.25.x - unstable featureX
> 3.26.x - stable

So this picture would actually be:

3.20.x - oldstable
3.21.x - unstable relp - closed
3.11.x - stable
3.23.x - unstable tls
3.25.x - unstable tls+featureX

That actually bring us down to three branches (plus old legacy like v2
stable):

- stable
- stabilizing (branched off the dev tree and in the bugfix wait queue
- devel

There may be more than one stabilizing tree at a given time (not yet
thought out). In recent history, we have one such sample. That is the
queue engine. It was an extremely big overhaul of nearly everything. So
it needed some extended time to mature. In the mean time, some more
focus features could be implemented. With the version numbering system I
have now on my mind, that would probably have looked as follows (I am
intentionally using major version 999 to avoid confusion with existing
versions):

999.2.0 - stable
999.3.x - big overhaul feature, stabilizing
999.5.x - .3 + next focus feature, stabilizing
999.7.x - .5 + next focus feature, stabilizing
999.9.x - devel

Actually, we are happy with the feature introduced in 999.7.x. But we
won't release a new stable because .5 is not yet ready for prime time.
So nothing happens at that point. Then, we are confident in .5. I think
the following happens then:

999.2.0 - deprecated stable
999.3.x - big overhaul feature, stabilizing
999.5.x - .3 + next focus feature, stabilizing
999.7.x - .5 + next focus feature, stabilizing
999.8.0 - stable
999.9.x - devel

We will never see a 999.6. I personally think this is acceptable,
especially as I think it won't happen very often.

Does that make more sense?

> or similar.
>
> that is kind of odd ...
>
> rainer: what do you think about only having one dev tree and
> having some patchsets for not-that-much-worked-on features
> (e.g. tls, featureX). of course, you can arrange your repository as
> you wish, but i would stick to *one* stable version and *one* dev
> version for the testers.
>
> everything else should be build (as patches) on top of these 2
> branches.

I am a bit concerned that I need to be too careful which patch I apply
where. As you know, rsyslog is developed on a very fast pace and I'd
rather prefer to keep coding instead of thinking where I add a
"by-feature" (that maybe takes an hour to implement). The scheme I am
currently trialing (outlined above) works pretty OK. It is some
additional overhead, but I mostly do everything to the trunk, create a
patch for bugfixes and apply that to the "old" version in question. Some
more work than before, but quite bearable.

Of course things are different if I work on a feature, abandon it, and
go back after a few weeks. But currently I implement everything up to a
usable state (maybe not 100%, but useful in what is there) before I take
the next step.

Again... comments please ;)

Rainer

> as a nice effect, we will have only 1 stable core and 1 dev core and
> have no issues when it comes to merging core-relp with core-tls with
> core-featureX.
>
> 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

2008/4/4, Rainer Gerhards <rgerhards at hq.adiscon.com>:
>
> 999.2.0 - stable
> 999.3.x - big overhaul feature, stabilizing
> 999.5.x - .3 + next focus feature, stabilizing
> 999.7.x - .5 + next focus feature, stabilizing
> 999.9.x - devel
>
> Again... comments please ;)

I think you really should try to use git feature branches for that.
Have a stable and master (development) branch, and develop the
features in separate topic branches feature-A, feature-B etc.
Whenever one feature is ready, merge it into master.
This way, it doesn't matter which feature you have to concentrate on
is released first (no skipped version numbers!).
The strong merge suppport in git would also allow to cherrypick easily
from the different feature branches or merge between them.

Cheers,
Michael


--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

> 2008/4/4, Rainer Gerhards <rgerhards at hq.adiscon.com>:
> >
> > 999.2.0 - stable
> > 999.3.x - big overhaul feature, stabilizing
> > 999.5.x - .3 + next focus feature, stabilizing
> > 999.7.x - .5 + next focus feature, stabilizing
> > 999.9.x - devel
> >
> > Again... comments please ;)
>
> I think you really should try to use git feature branches for that.
> Have a stable and master (development) branch, and develop the
> features in separate topic branches feature-A, feature-B etc.
> Whenever one feature is ready, merge it into master.
> This way, it doesn't matter which feature you have to concentrate on
> is released first (no skipped version numbers!).
> The strong merge suppport in git would also allow to cherrypick easily
> from the different feature branches or merge between them.

Sounds good, but a honest question (NOT trying to give a bias, just a
problem description):

While I implement FocusFeatureX, I get Feature 1, 2, 3 requests and
implement them - all while FocusFeatureX is being developed. Where do I
apply these? And don't I get into trouble if that interferes with things
that I do in FocusFeatureX? Remember, I change a couple of hundered
lines all over the project on a typical day...

Rainer

> Cheers,
> Michael
>
>
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog

2008/4/4, Rainer Gerhards <rgerhards at hq.adiscon.com>:
> > 2008/4/4, Rainer Gerhards <rgerhards at hq.adiscon.com>:
> > >
> > > 999.2.0 - stable
> > > 999.3.x - big overhaul feature, stabilizing
> > > 999.5.x - .3 + next focus feature, stabilizing
> > > 999.7.x - .5 + next focus feature, stabilizing
> > > 999.9.x - devel
> > >
> > > Again... comments please ;)
> >
> > I think you really should try to use git feature branches for that.
> > Have a stable and master (development) branch, and develop the
> > features in separate topic branches feature-A, feature-B etc.
> > Whenever one feature is ready, merge it into master.
> > This way, it doesn't matter which feature you have to concentrate on
> > is released first (no skipped version numbers!).
> > The strong merge suppport in git would also allow to cherrypick easily
> > from the different feature branches or merge between them.
>
>
> Sounds good, but a honest question (NOT trying to give a bias, just a
> problem description):
>
> While I implement FocusFeatureX, I get Feature 1, 2, 3 requests and
> implement them - all while FocusFeatureX is being developed. Where do I
> apply these? And don't I get into trouble if that interferes with things
> that I do in FocusFeatureX? Remember, I change a couple of hundered
> lines all over the project on a typical day...

Say you work on a featureA branch. Now you get an unrelated feature
request for featureB.
You'd switch back to current master, and branch of featureB, starting
to work on that.
By the end of the day, say featureB is ready, you'd merge those branch
back into master (and delete branch featureB if no longer required).
If featureC is dependend on featureA, you can branch from there. If
you now work again on featureA, and later on featureC, you can merge
the new commits from featureA back into featureC again.
Later, when featureA and C are ready, you merge them into master again.
For small changes, I'd directly work on master and commit there. There
is also a nice feature called git-stash, which allows to put
uncommitted changes away, work temporarily on other stuff, an get back
to the uncommited stuff later.

I'd say, just test git and try to get a "feeling" for it. That
probably helps to make a better decision.

Cheers,
Michael



--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

OK, let me come to a conclusion ;)

What Michael writes and Raoul suggested makes an awful lot of sense.
Right now, I have two problems:

a) we are still having a bit of trouble with the git transistion of
rsyslog - I hope to have that sorted out soon
b) I need to invest some time to fully understand how git branches.

The bigger problem is probably b). Thankfully, I have started to work
with git on librelp and it was a very good experience. It still looks
like I need to invest at least a day or two more into getting fully
involved with it. That doesn't sound much, but there is a lot I can do
in rsyslog in this time.

I think I will proceed as follows:

For the next few weeks, I'll use the scheme that I outlined this
morning. It works and it is sufficiently clean for the time being.
Especially as I don't see any reason for gaps, there is no such major
overhaul in sight.

While I do so, I'll get more acquainted to git and see how I can make
utilize its branching capabilities. At some point in time (and if
everything works as well as advertised, what I assume ;)), I'll switch
to the git feature branch strategy. My hope is all this can be done in
the next 10 weeks or so.

I hope I don't disappoint anyone - but the problem is things to do. All
needs to go by priorities and, quite honestly, TLS or the new config
file format is higher on my priority scale than the branching strategy.
And, yes, I know good knowledge with git will save in the long run. But
I need to start somewhere ;)

I someone has serious concerns on the route I am taking, please scream
now ;)

Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Michael Biebl
> Sent: Friday, April 04, 2008 12:02 PM
> To: rsyslog-users
> Subject: Re: [rsyslog] rsyslog version numbering
>
> 2008/4/4, Rainer Gerhards <rgerhards at hq.adiscon.com>:
> > > 2008/4/4, Rainer Gerhards <rgerhards at hq.adiscon.com>:
> > > >
> > > > 999.2.0 - stable
> > > > 999.3.x - big overhaul feature, stabilizing
> > > > 999.5.x - .3 + next focus feature, stabilizing
> > > > 999.7.x - .5 + next focus feature, stabilizing
> > > > 999.9.x - devel
> > > >
> > > > Again... comments please ;)
> > >
> > > I think you really should try to use git feature branches for
> that.
> > > Have a stable and master (development) branch, and develop the
> > > features in separate topic branches feature-A, feature-B etc.
> > > Whenever one feature is ready, merge it into master.
> > > This way, it doesn't matter which feature you have to concentrate
> on
> > > is released first (no skipped version numbers!).
> > > The strong merge suppport in git would also allow to cherrypick
> easily
> > > from the different feature branches or merge between them.
> >
> >
> > Sounds good, but a honest question (NOT trying to give a bias, just
a
> > problem description):
> >
> > While I implement FocusFeatureX, I get Feature 1, 2, 3 requests and
> > implement them - all while FocusFeatureX is being developed. Where
> do I
> > apply these? And don't I get into trouble if that interferes with
> things
> > that I do in FocusFeatureX? Remember, I change a couple of hundered
> > lines all over the project on a typical day...
>
> Say you work on a featureA branch. Now you get an unrelated feature
> request for featureB.
> You'd switch back to current master, and branch of featureB, starting
> to work on that.
> By the end of the day, say featureB is ready, you'd merge those branch
> back into master (and delete branch featureB if no longer required).
> If featureC is dependend on featureA, you can branch from there. If
> you now work again on featureA, and later on featureC, you can merge
> the new commits from featureA back into featureC again.
> Later, when featureA and C are ready, you merge them into master
again.
> For small changes, I'd directly work on master and commit there. There
> is also a nice feature called git-stash, which allows to put
> uncommitted changes away, work temporarily on other stuff, an get back
> to the uncommited stuff later.
>
> I'd say, just test git and try to get a "feeling" for it. That
> probably helps to make a better decision.
>
> Cheers,
> Michael
>
>
>
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog