Hello,
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 "Fixlabel"
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
Eclipse CVS
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
Greetings
--
Jürgen Knuplesch
-----Ursprüngliche Nachricht-----
Von: address@hidden [mailto:address@hidden
] Im Auftrag von Greg Akins
Gesendet: Dienstag, 7. Juli 2009 17:13
An: address@hidden
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)
--
Greg Akins
http://www.pghcodingdojo.org
http://pittjug.dev.java.net