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