2008/3/31, Rainer Gerhards <[EMAIL PROTECTED]>: > 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.
The point is, that the don't try to draw a line where they start calling something alpha, beta then rc. The simply use one, rc, and increment that. > > > > > 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 problem is, that for package management systems (and for people) 3.12.x > 3.1.x > 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? This only happens, if you have two unstable branches at the same time. Do you expect that to happen that often? 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
