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
No. > > svn cp https://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk > https://svn.apache.org/repos/asf/tomcat/trunk > Yes that more similar to httpd so that probably a better solution. > and then > - Make all changes in trunk (CTR) We should have a roadmap of what we want to do before starting. > - Port those API changes we want in 6.2.x from trunk to 6.1.x (RTC) > - A beta release of 6.1.x tagging trunk. > - Once we are happy with 6.1.x, freeze it, create 6.2.x and do a > stable release 6.2.x will then be like the actual https://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk > - 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 We could have beta 6.3.x tags of trunk at that time. Cheers Jean-Frederic > > Mark > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
