Rainer Gerhards wrote: i clearly object this numbering scheme as it gives much trouble to both ppl and package maintainers. moreover, i would see the 3.x.y branch as a branch depending on some "old" kind of version numbering and start with a fresh version scheme from 4.x.y onwards.
coming back to your example, what would you think of: > 3.13.0 is the current stable. > 3.13.5 stable 3.13.5-relp5 (3.80.5 relp) 3.13.5-relp+tcp2 (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.13.6-relp6 (3.80.6 relp) 3.13.5-relp+tcp3 (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.14.0-tcp3 (3.81.3 rep/tcp unstable) 3.13.6 deprecated 3.14.0 stable relp 3.14.3-tcp3 (3.81.3 relp/tcp unstable) 3.14.0-tls (3.82.0 relp w/ tls unstable) > Now tcp becomes stable: 3.13.6 deprecated 3.14.0 stable relp 3.15.0 relp/tcp stable 3.15.0-tls (3.82.0 relp w/ tls unstable) this means we're basically working with patches which can be applied on top of the current stable release. in git you can of course maintain them as branches and merge as to your liking. cheers, raoul -- ____________________________________________________________________ DI (FH) Raoul Bhatia M.Sc. email. [EMAIL PROTECTED] Technischer Leiter IPAX - Aloy Bhatia Hava OEG web. http://www.ipax.at Barawitzkagasse 10/2/2/11 email. [EMAIL PROTECTED] 1190 Wien tel. +43 1 3670030 FN 277995t HG Wien fax. +43 1 3670030 15 ____________________________________________________________________ _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog
