Branching vs Tagging for release candidates

[Greg Akins]

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