Peter, Ah, so you compare the strings... makes sense. But also makes clear we have a problem with any such scheme...
... that means it applies to Johnn's suggestion, too :( Next try, back to odd/even. So any odd version number is unstable, any even one is stable. Once something gets stable, it is incremented to the even version. -rc and similar things may (may!) be added to alert users. Again into the sample case: 3.14.0 stable 3.15.6 unstable (relp) 3.17.2 unstable (relp/tcp) Now let's assume I add a bugfix for the core engine. Would that bring us to 3.14.1 stable 3.15.7 unstable (relp) 3.17.3 unstable (relp/tcp) Once relp is stable, we have 3.14.1 deprecated 3.16.0 stable (relp) 3.17.3 unstable (relp/tcp) TLS begins: 3.14.1 deprecated 3.16.0 stable (relp) 3.17.3 unstable (relp/tcp) 3.19.0 unstable (tls) Now tcp becomes stable: 3.14.1 deprecated 3.16.0 deprecated 3.18.0 stable (relp/tcp) 3.19.0 unstable (tls) In all cases stable > devel, at least as far as the some feature set is concerned. There may be gaps in the minor version numbers when versions are not yet stable. Does that work? Rainer > -----Original Message----- > From: Peter Vrabec [mailto:[EMAIL PROTECTED] > Sent: Monday, March 31, 2008 4:51 PM > To: [email protected] > Cc: Rainer Gerhards > Subject: Re: [rsyslog] rsyslog version numbering > > Hi, > > > 3.13.6 stable > > 3.14.0-dev7 (relp) > > 3.15.0-dev4 (relp/tcp) > > > > Once relp is stable, we have > > > > 3.13.6 deprecated > > 3.14.0 stable relp > > 3.15.0-dev4 (relp/tcp) > > There is a great disadvatage of this scheme. > 3.14.0-dev7 > 3.14.0, BUT 3.14.0 is newer. _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog
