Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Ryan Parlee wrote:
> Can someone please review my current tagging/branching methodology and make
> sure I'm doing this right:
>
> ## Rule 1: Do all new (i.e. unstable) work on HEAD
>
> ## Rule 2: Do formal bug fixing on a branch:
>
> ## Rule 3: Once formal testing period is complete, tag the TEST branch using
> a "stable" release number and release to clients:
>
As Arthur has already said: Your best parctise depends on your workflow.
Here is how what we do:
We are about 13 developers working on one product. We commit all new
stuff to HEAD. At some point, when we are getting closer to the release
and one part of the team starts working on stuff that gets to the next
(not the coming) release, we make a branch for the release, e.g. the new
stuff for the next release still goes to HEAD, the bugfixes for the
coming release go to the branch _AND_ to the HEAD (merge). This branch
is also used after the release for our service packs and it's also the
same policy: Bugfixes for the service pack go the the branch and to the
HEAD.
We used to tag every installable release (also internal ones), but this
might change in the future as it turned out that we get way to many tags
and most of them are never used again, so I think we're going to tag
releases that gets out, e.g. betas.
Long story short: New stuff to HEAD, for every release a branch. Tags
for external releases.
Best regards
Andreas
--
Andreas Tscharner <andy at vis.ethz.ch>
----------------------------------------------------------------------
"Intruder on level one. All Aliens please proceed to level one."
-- Call in "Alien: Resurrection"