Re: RFC:PHP Release Cycle

In article <Pine.LNX.4.21.0011141052170.31802-100000@joeysmith.com>, joey@joeysmith.com wrote: > I really would like to see branches for every RC. That way, > development could continue on the trunk. I want this so badly, I will > commit to spending my allocated QA time on tracking & mergeing into the > trunk any changes made on RC branches. Since this was the only real > complaint I ever heard against branches, maybe this will actually get us > somewhere? :) chiming in way late. having used cvs branches more extensively than perhaps anyone ever should at my last job (lets just say that frequent merging from branches in one module into other modules was involved :), i have to say they're notquite as evil as some people seem to think, as long as you watch your step and use them consistently. you don't want a branch per release candidate -- you want a branch for each release version. the steps would look something like this for a future php version: cvs rtag -b BRANCH_PHP_4_0_10 php4 cvs co -r BRANCH_PHP_4_0_10 -d php4_0_10 php4 cd php4_0_10 cvs tag PHP_4_0_10_RC_1 ... build, distribute, test, check in changes to the branch, etc ... cvs tag PHP_4_0_10_RC_2 ... build, distribute, test, check in changes to the branch, etc ... cvs tag PHP_4_0_10_FINAL ... release ... cvs up -A cvs up -j BRANCH_PHP_4_0_10 ... fix conflicts ... cvs tag PRE_MERGE_FROM_PHP_4_0_10 php4 cvs ci -m "merged bug fixes from 4.0.10 release cycle" cvs tag POST_MERGE_FROM_PHP_4_0_10 php4 and then never touch BRANCH_PHP_4_0_10 again. you could also easily skip the last steps and require that people check in bugfixes to both the HEAD and the appropriate branch. the only problems i've had with merging branches in cvs is when merging between two branches frequently and not taking care to merge the difference from between the correct checkpoints on the branch. but in the scheme above, the merge between branches is only ever done once and then the branch is retired, so it shouldn't be much of an issue. for what its worth, the loginfo/commitinfo scripts should tag emails that get sent out with the branch name when they are commited to a branch. that helps keep an eye on things. (oh, and just an aside to the idea in the original proposal about another bug database used for release cycles -- just add the correct column or severity level ("release critical") to the one true bug system. having two systems will just increase the odds of a bug getting overlooked, and it makes it harder to track the history of bugs because you've doubled the number of places to have to look.) jim