Quick comment... Others please also comment... > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:rsyslog- > [EMAIL PROTECTED] On Behalf Of Michael Biebl > Sent: Monday, March 31, 2008 12:48 PM > To: rsyslog-users > Subject: Re: [rsyslog] rsyslog version numbering > > 2008/3/31, Rainer Gerhards <[EMAIL PROTECTED]>: > > I'll do a new release according to the new versioning scheme > > (3.13.0-rc1) later today if nobody objects. It's still not > finalized, > > but doing so makes everybody aware and is also a test for me (plus, > we > > could move to 3.13.0 [stable] on April, 2nd). > > > > Ok, a few comments: > I thinks the distinction between mf? (minor features) and rc? (major > features) is a bit artifical and counterintuitive imho. > For me, rc means "release candidate", meaning that we are close to a > stable release (contrary to your proposal, where rc means major new > feature, possibly destabilizing a lot). Also, if I read your proposal > correctly, as soon as there was an rc1 release, there can be no more > mf? releases (even if the added features would be minor) > I'd rather use something like -pre1, -pre2 ... (no matter if you have > a major or minor feature) and if we are nearing a stable release > switch to -rc
It would be fine with me to call all -pre1, -pre2 etc... > Or you could do it like the kernel, and only use -rc?. To me, it is quite illogical to call something a -rc, when it not even contains the feature that it shall be a candidate for ;) That was the primary driver for -mf. > > Another proposal for the version scheme (slightly adopted from KDE or > Gnome): > As an example, your currently stable release is > 3.1.x, eg. 3.1.4. > Now you want to work against the next minor release, which would be 3.2 > So you start with > 3.1.80 (80 meaning alpha/beta quality) and increment the last digit > for every new release, eg. 3.1.81 (if you reach 89, you start > numbering 89.1..) > When you enter RC stage, you switch to > 3.1.90 and increment for each new release. The final release being 3.2. Well, that is somewhat along the lines of what I currently do. Remember, I start at 3.10.x for deve builds, then (in the original scheme), I'd go to 3.0, continue with e.g. 3.12.3, which becomes 3.1. The problem were the bouncing numbers. But maybe using patchlevel for that solves the issues. Let's use an actual sample. 3.13.0 is the current stable. The next major feature is RELP, which has been completed, but is not yet stable. I am now working on plain tcp TLS. So would this be the release numbers: 3.13.5 stable 3.13.87 relp 3.14.82 relp/tcp Now let's assume I add a bugfix for the core engine. Would that bring us to 3.13.6 stable 3.13.88 relp 3.14.83 rep/tcp Once relp is stable, we will have 3.13.6 deprecated 3.14.0 stable 3.14.83 rep/tcp unstable So actually the 3.14.0 release happens possibly much later than 3.14.80? And in that scheme we never have a development designation but the patch level contains it (being >= 80 implies being unstable, while being less implies being stable)? >From what I see, I think that would work for me. Rainer > > If you are working towards a next major release, you would start with > 3.80 -> 3.90 -> 4.0 > > Cheers, > Michael > > [1] If you run out > -- > 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 _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog
