Promoting Changes to QA/Production
http://mail.gnu.org/pipermail/info-cvs/2002-January/023205.html
By Pierre Asselin <lpa@cutter.rexx.com>
This email was in the same thread as NightlyBuildsAndTags, and appears to fit the Beta -> Release Candidate -> Stable model quite well. Here are the main points:
- Development is on the trunk. When the product has the features we want, we tag the tip of the trunk for a QA-release and start hacking on newer features.
- QA starts a QA-bugfix branch off of development's QA release, and starts looking for bugs. Bug fixes are committed to the QA bugfix branch.
- When QA-bugfix looks good, it gets tagged as Production release, while bugs continue to get fixed on QA-bugfix
- Bug reports from production are fixed on the QA-bugfix branch, a new Production release is tagged, and production takes that. So, with Pierre's method, all bugs found in "RC" and "Beta" are fixed in "Beta", and will get moved up in time.
- After a while the QA-fixes branch is merged to the trunk, so Development has the bug fixes too.
- Eventually, Development makes a new QA release. A new QA-fixes branch is started, and the old one is abandoned.
General Rules
- Always know why you created a branch, and stick to the rule
- Merge in one direction only: new features go to QA and never to QA-fixes.
... back to Software Engineering Resources