Re: Branching vs Tagging for release candidates

[Todd Denniston]

Greg Akins wrote, On 07/07/2009 11:12 AM:
> 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)

I would like to suggest looking at what some of what Brad Appleton has 
documented. It may not give exactly the answers you need, but it will probably 
help you discuss what you want to do with others.

http://www.cmcrossroads.com/bradapp/acme/branching/#StreamedLines

http://www.cmcrossroads.com/bradapp/acme/branching/

http://www.cmcrossroads.com/bradapp/acme/


++ Are you trying to make a release candidate from a mainline that has all the 
functionality that you want for the release, but needs QA and bug fixes.

in that case I think what might serve you well is a "Parallel 
Maintenance/Development with a LAG Development Line"
http://www.cmcrossroads.com/bradapp/acme/branching/branch-structs.html#ParallelMaintDev
make the "Maintenance"/Release branch

++ Or Are you trying to make a release candidate that lets folks see condition 
of the current stable state of development?

in this case I think a Docking or Staged line setup would be better
http://www.cmcrossroads.com/bradapp/acme/branching/branch-structs.html#DockingLine
http://www.cmcrossroads.com/bradapp/acme/branching/branch-structs.html#StagedLines
Though if there is more than one new feature going in, you might want to have 
multiple devel_line branches, one for each feature until each feature is 
stable enough to be inflicted on others.
http://www.cmcrossroads.com/bradapp/acme/branching/branch-policy.html#MYOC

--
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter