Hi Peter, thanks for the feedback. So it looks like we go for the 4-number scheme.
If I look at the migration case, I am tempted to do a one-time move to 4.0.x.x (stable) and 4.1.x.x (devel) and drop the v3 tree (flagged as interim devel release) to prevent any confusion about version numbers. Changing from a 3-number to a 4-number scheme within the same major release sounds confusing in itself to me. Any concerns with such an approach? Anyone? Rainer > -----Original Message----- > From: Peter Vrabec [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 26, 2008 11:47 AM > To: [email protected] > Cc: Rainer Gerhards > Subject: Re: [rsyslog] rsyslog version numbering - was: RE: rsyslog > 3.0.0 stable? - feedback, please > > Hi, > > politicalmajor.major.minor.patchlevel seems good to me. > > politicalmajor - something great happened, like v2 and v3 > > major - odd, even - developer/stable release > > minor - new features > > patchlevel - patchlevel > > so current 3.12.4 becomes 3.0.12.4 > > development starts with 3.1.0.0 and continues to > > 3.1.0.1, 3.1.0.2, 3.1.1.0, 3.1.2.0, ... 3.1.6.10 > > than we decide to release stable > > 3.2.6.0, 3.2.6.1, 3.2.6.2 > > or > > 3.2.0.0, 3.2.0.1, 3.2.0.2? > > development 3.3.0.0, ... 3.3.x.y > > There is one problem 3.12.4 > 3.0.12.4 == problem with upgrade > > solutions: > > 1) 3.12.4 -> 3.14.0.0 > > 2) 3.12.4 -> 3.0.12.4 and I'll start new epoch of rsyslog package > > (Epoch: 2 in specfile, don't know how is it in other distros) > > On Tuesday 25 March 2008 06:16:05 pm Rainer Gerhards wrote: > > > Hi all, > > > > > > I have thought about the version numbering. Obviously, the old scheme > > > (http://www.rsyslog.com/doc-version_naming.html ) is confusing and > > > should be dropped. > > > > > > Rsyslog currently follows a three-number version scheme: > > > > > > major.minor.patchlevel > > > > > > I can follow an odd/even scheme on major for unstable/stable > branches. > > > However, with major features being continuously introduced may bring > us > > > to rsyslog 10.x.x by the end of the year. While I have no hard > concerns, > > > it seems to be unusual for open source to increase the major version > > > that fast. On the other hand, I need minor.patchlevel to handle the > > > smaller fixes and new major feature. I increase minor for each new > > > feature (like queue engine, expression-based filters, relp, to name a > > > few actual ones) and increase patchlevel for smaller changes. The > three > > > number scheme works well, but, again, keeps the major number very > > > quickly growing given the current fast pace of development. > > > > > > An alternative would be to use > > > > > > politicalmajor.major.minor.patchlevel > > > > > > Where politicalmajor would only be incremented every now and then and > > > actually without much technical reasoning for doing so - only then > when > > > we "feel" it is time for a new major release. It would probably turn > out > > > to be incremented around once a year, just to keep the corporate > folks > > > happy and the major version number reasonable low. > > > > > > Question now: which scheme should I follow? Is there any other one? > If > > > so, why should I follow that other scheme? > > > I would appreciate quick feedback, as I'd like to settle this issue > > > before releasing RELP support, which currently looks like some time > > > (very) early April. > > > > > > Thanks, > > > Rainer _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog
