Re: Branching vs Tagging for release candidates

Another approach is to apply your bug fixes to the release branch,  
then merge them to the trunk.  This has the advantage that the merges  
will be simpler because you don't have to try to separate maintenance  
from new development.  The risk is that the trunk may suffer  
regressions (due to missed merges) but if your QA department is on the  
ball then they should apply the bug fix test cases to the new  
development.

You can also use a method like submit/assemble to control the  
introduction of change into your release candidates.  That method  
divorces the release candidate from the head of the relevant branch  
and allows the selective inclusion or exclusion of sets of related  
versions corresponding to bug fixes or features.  It also does a kind  
of dependency check if there are overlaps in the source files  
implementing the fixes or features.

On Jul 7, 2009, at 11:49 PM, Knuplesch, Juergen wrote:

>
> 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: [email protected] [mailto:[email protected] 
> ] Im Auftrag von Greg Akins
> Gesendet: Dienstag, 7. Juli 2009 17:13
> An: [email protected]
> 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
>
>
>
>

--
Is it "living the dream," or is it "schizophrenia"?
Paul Sander
[email protected]