William A. Rowe, Jr. wrote: > 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 :)
The best is to start from a tagged version of tc-6.0.x. Cheers Jean-Frederic > > Bill > > --------------------------------------------------------------------- > 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]
