Ah, the source of the misunderstanding finally hits me... > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:rsyslog- > [EMAIL PROTECTED] 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. [EMAIL PROTECTED] > Technischer Leiter > > IPAX - Aloy Bhatia Hava OEG web. http://www.ipax.at > Barawitzkagasse 10/2/2/11 email. [EMAIL PROTECTED] > 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 mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog
