Mark Thomas wrote: > William A. Rowe, Jr. wrote: >> Actually, the way it typically works at httpd-space (which your new >> policy is based on) is that you would next create 6.1.0 as a forever >> development branch. Committers apply each patch they believe belongs >> to the 6.2.0 release, and things are removed and readded as various >> votes and discussions proceed. > > OK. I think I have it now. Does the the following make more sense? > > svn cp https://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk > https://svn.apache.org/repos/asf/tomcat/tc6.1.x/trunk > > svn cp https://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk > https://svn.apache.org/repos/asf/tomcat/trunk > > and then > - Make all changes in trunk (CTR) > - Port those API changes we want in 6.2.x from trunk to 6.1.x (RTC) > - A beta release of 6.1.x > - Once we are happy with 6.1.x, freeze it, create 6.2.x and do a > stable release > - Continue to port non-API modifying changes from trunk to 6.2.x as RTC > - At some point in the future, trunk is branched to form 6.3.x which > is used as the basis for 6.4.x or 7.0.x
Yup, my only kibitz would be that you /might/ want to consider deferring the creation of trunk for a week to copy it from 6.1.x. in order to let people catch up with the backlog of patches, without having to apply them in /both/ places at once :) Bill --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
