> From: [EMAIL PROTECTED] [mailto:rsyslog- > [EMAIL PROTECTED] On Behalf Of Michael Biebl > Sent: Monday, March 31, 2008 1:10 PM > To: rsyslog-users > Subject: Re: [rsyslog] rsyslog version numbering > > 2008/3/31, Rainer Gerhards <[EMAIL PROTECTED]>: > > Question ;) > > > > > > > If you are working towards a next major release, you would start > with > > > 3.80 -> 3.90 -> 4.0 > > > > > > That also means once we have reached 3.80, we can/will no longer > apply > > the new features to the 3.x stable tree, but rather only the 4.x > stable > > tree? I am asking because I just realized we would otherwise be back > to > > the up and down bouncing version numbers - this happens to be > exactly > > the scheme I used so far... > > I don't see the problem here. > Say you have a current 3.2.1 stable release. > Then you start working for the next major release 4. > After 4.0 has been released, you want to add a new feature to the old > stable branch, so you release 3.3.0. > That's something completely different than renaming 3.12.x to 3.1 when > it becomes stable.
I was thinking about the .80+ case. Back to the sample, this time just assuming that relp is scheduled for the next major release. 3.13.0 is the current stable. 3.13.5 stable 3.80.5 relp 3.81.2 relp/tcp Now let's assume I add a bugfix for the core engine. Would that bring us to 3.13.6 stable 3.80.6 relp 3.81.3 rep/tcp Once relp is stable, we will have... well, what will we have? RELP is stable, but the v4 goal is not yet reached? I thought it means it'll become 3.14.0: 3.13.6 deprecated 3.14.0 stable relp 3.81.3 rep/tcp unstable But now we are back to a case wher 3.81.6 (higher version number) is the same a 3.14.0. And now let's consider: 3.13.6 deprecated 3.14.0 stable relp (based on 3.80.6) 3.81.3 relp/tcp unstable 3.82.0 relp w/ tls unstable Now tcp becomes stable: 3.13.6 deprecated 3.14.0 stable relp (based on 3.80.6) 3.15.0 relp/tcp stable (based on 3.81.3) 3.82.0 relp w/ tls unstable But now we have the situation that 3.15 is more capable than 3.80. This is what I meant. It's exactly the scheme rsyslog used so far, except that I started unstable builds at .10 and not .80. If things working towards a new release shall start with .80, we need to either hold development on the stable (just as I did so far) or we need to have more capable builds with fewer IDs. Maybe this whole stable/unstable thing is not really worth the trouble and I should instead provide the feature stability matrix instead - where for each feature is shown how mature it is. Actually, I'd think that would probably make up for better information. Comments please. Rainer _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog
