Rainer Gerhards wrote: >> inside the development tree, one could do: >> 4.1.0 = new dev release >> 4.1.1-rc1 = major new features - exerimental - only for hardcore >> testers >> 4.1.1-rc2 = getting more stable >> 4.1.1-rc3 = getting more stable >> 4.1.1 = let more ppl test this release with its new features >> >> 4.1.2-rc1 = new features, new fixes, based on 4.1.1. 4.1.1. will not > be >> continued/patched/etc. > > I see where you are coming from. This is actually a three and a half > version numbering scheme - but also makes sense to me. Looks like a good > solution. I like this much more than suggestion B, I have to admit ;) -- > the main reason is that I tend to commit very frequently, but a nightly > release will probably bad to follow up on.
I like this idea too (or the general direction of it, anyway -- I'm sure once you start down it, you will likely tweak it to fit actual needs). It lets you keep the 3-number scheme, while still providing for interim releases that don't overload the version number. And a few other projects seem to use this scheme too (consistency is good). > Overall, these suggestions look easier to follow than mine. So if nobody > objects, I'll implement them by mid next week. BUT... Feedback is still > most welcome! So, starting next week, there will be 3 branches? * 2.0.x -- stable, this is the one that systems like RHEL will track for awhile * 3.12.x -- what is this called? this is the "new" stable, for those that need the new 3.x features, but also want a relatively stabilized version, once the numbering is sufficiently high * 4.0.x -- devel, this is where the new major features start going in I think this works. Actually, taking a look at mysql just for comparison sake, they appear to have something similar: 5.0.x (for super-stable, like RHEL), 5.1.x (for those who need full NDB support, but mostly stable once it comes out of RC), and 6.0.x (alpha). johnn _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog
