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