In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (Matt) writes:
>Our project has recently reached a maintenance >phase, so we have a few people working on bug fixes and small >enhancements and we have another couple of people working on one major >enhancement. >[ ... ] >The answer may be to use the branch for the maintenance work, That's how it's normally done. Treat the milestone as a "release to QA", requiring a tag. Start a bugfix branch off the release point. The maintenance team works on that branch, the development team continues its work on the trunk. >From time to time, merge bug fixes from the maintenance branch to the trunk; plant a moving tag (cvs tag -F ...) at the tip of the branch after every such merge, to keep track of what's already merged. >but in order to not get enhancement code into >regular production builds, we would have to maintain the single branch >until the time when the enhancement is finished and they can be >merged. They're always merged. The trunk (enhancement) has all the bugfixes because you keep merging from branch to trunk. When the enhancement work is ready for QA, you repeat the process and start a second branch. You maintain the first branch for as long as you support the un-enhanced version, for example if you ship to customers and sell them support contracts. You should merge further bug fixes to the later maintenance branches and to the trunk. Hopefully the fix rate will start slowing down. When you drop support, you just stop working on the branch. _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
