Branching vs Tagging for release candidates

[Knuplesch, Juergen]

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