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
