On Wed, 7 Mar 2001, Bordet, Simone wrote:
There seems to be a lot of confusion about what exactly everyone is
proposing here, so please allow me to summarise what I think are the best
points of each.
* Development of new features is done on the trunk. Commits here require
no tagging.
* When the release manager (marc?) is happy with the features in the
trunk, a branch is created for the next version (say, 2_4).
* When the release manager is happy with the stability of the branch,
a new release is tagged, say 2_4_0.
* Every time a developer commits a patch on that branch, he must re-tag
it, say as 2_4_1, AFTER ensuring the tests all run correctly.
* Every time a developer commits a patch on a branch, he must consider, in
consultation with other developers, whether it is needed in the
trunk, and if so apply it there. *Carefully*.
* Similarly, when a developer commits a bug-fix (NOT new feature) on the
trunk, he must consider whether it is required in the branch for
the latest release.
* Old branches die when a new branch is created.
That way we don't end up with messy 'stable' or 'patches' tags, don't have
horrible tags like the 'rel_2_4_build_20013007' or some such which someone
suggested (can you imagine typing that regularly? no tab completion
here...), and it's simple enough that people might actually stick to
it. Since there is no real central control over the repository, this is a
significant consideration. If something is too complicated, people will
just do it their own way, which is easier and non-standard. My signature
is in fact a restatement of this principle.
My HO.
Tom
--
"If you mess with something for long enough it will break."
- Schmidt's law of engineering
