Ross Gardler wrote:
So can someone start me off...
Well, here's a few starting points that I've gleamed from working with or on various projects, including large, free software projects (Mozilla, FreeBSD), my own potterings, and projects at work.
I'm not saying Xindice should follow all of these suggestions off the bat, but they are something to aim for as the project grows. I'd suggest that the basic branch management (the first few points below) is something to aim for initally.
** Branch management
Make a branch for every official release when it is feature-complete, and tag the actual release code and any RC-style releases. Make RC-style releases from the release's branch. Eg:
(note: a '|' indicates a tag)
==================================> trunk
\
\---|-----|-----| 1.0 branch
rc1 rc2 1.0If you do make more, minor bigfixes to a release branch, you may as well apply them to the same branch but use tags for the minor RC's (if any) and for the minor point release. Eg:
==============================/ /======================> trunk
\
\---|-------|-------|-----/ /----|----------| 1.0 branch
1.0-rc1 1.0-rc2 1.0 1.0.1-rc1 1.0.1If large, far reaching changes are being made on the trunk, such as refactoring for an upcoming 2.0 release, but stable development work is continuing the existing major release, do the stable work on a long-lived, stable branch. Then make point releases from branches off the stable branch, with each point release managed as above. Eg:
====================================> trunk (2.0 work)
\----------------------------------> 1.0 branch (ongoing stable work)
\--| 1.1 \--| 1.2 \--| 1.3
** Code and commit management.
Prior to cutting a new branch, freeze (close) the tree to all unapproved commits to the branch you're cutting it from for a period of time (from a few days up to a week). You don't want people landing destabilizing changes just before you cut for a release.
Approval should also be sought to commit patches to a release branch.
Approval should be by some pre-determined process, such as the getting a review by one or more commiters, for example, and when determining if a patch should be applied, the people involved should include actaully eyeball the proposed patches. On a closed or release branch, the only patches that should be accepted are those which are throughly tested bug fixes - no new features or large changes should land.
Use a bug tracking system such as Bugzilla. Fixes for particular bugs should be attached to the bug itself as a patch so that it can be easily reviewed and applied to multiple branches, if needed. If approval is required and given, it can be recorded in the bug.
I'm sure I'll think of some more stuff, but the following are interesting reading on the subject:
- General CVS guide for branching: <http://www.loria.fr/~molli/cvs/doc/cvs_5.html#SEC49>
- The Mozilla hacking guide: <http://www.mozilla.org/hacking/>
-- Mike Gratton <[EMAIL PROTECTED]>, <http://web.vee.net/> Leader in leachate production and transmission since 1976.
