[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Branching vs Tagging for release candidates

From: Todd Denniston
Subject: Re: Branching vs Tagging for release candidates
Date: Wed, 08 Jul 2009 22:25:19 -0400
User-agent: Thunderbird (X11/20081209)

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.

++ 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"
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
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.

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]