Thanks for asking this good question I struggle myself a lot! So I know I am
not alone in the univers with this challenge.
I think there is no perfect solution.
"I still havent found what Im looking for."
We use the following:
1.Every new version we release becomes a branch. (You only use HEAD) 2.The
first revision of the new branch is build into a basic version of our product.
3.The developers develop happily on the branch. They comit by using a number
(from our tracking system) that specifies the bug or requirement.
4.As soon as a bug or Req is finished, they mark all Resources in CVS with a
5.Then we create very often a Fix, by taking all resources that are fixlabeled
into a ever increasing jar.
Creating the fix is still a tough job. (The release team are two people that
have a lot of other responsibilities) The Release team has to make sure:
1.That every resource that is needed has the Fixlabel an is so included in the
Fix 2.That no resource that is not finished comes into the fix (e.g. res 1 is
comitted first for Bug 12 and then for Bug 10 - Bug 10 has to be released and
Bug 12 not. This is a conflict the releas team has to solve) 3.So for every fix
we create a list of Items that go into the fix and for every Item a list of
ressources belonging to the Item. Then we check every ressource that wants to
go into the Fix, if it is on the lists.
4.Make sure that the fix runs.
We achieve this by using
A Tracking system for Bugs and requirements called CodeBeamer that has a CVS
plugin so that every CVS comit is related to a number in the tracking system.
A tool that creates the lists of comits for each Trackingsystem Item
[mailto:info-cvs-bounces+juergen.knuplesch=icongmbh.de@xxxxxxxxxx] Im Auftrag
von Greg Akins
Gesendet: Dienstag, 7. Juli 2009 17:13
Betreff: Branching vs Tagging for release candidates
I'm struggling with getting release candidates ready while still allowing my
development team to work on new functionality. Doing some parallel work
instead of working serially on all new features.
My concern is stability of the RC while not adding too much development
overhead. Can anyone provide some advice to me?
For the version I just released, we created a Branch for the version that was
going out the door (6.1). Most bug fixes were applied to HEAD and merged into
the 6.1 Branch. That started to deteriorate as the HEAD got further away from
the Branch. And the dev team complained that they lacked confidence that
merges were getting applied correctly.
It was suggested that simply moving a tag around (re-tagging files that had
been fixed in the HEAD) and building from the tag would be better. This seems
reasonable. Is it? The only thing I can think of that would cause problems is
if the new revision of a file can't be applied to the Tag wholesale (if the
"merge" would have to be more selective to avoid incorporating new features).
Does anyone have any advice on the best way to accomplish this? Our dev team
is small (me & 2 developers)