[Top][All Lists]

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

Re: Branching vs Tagging for release candidates

From: Alan D. Salewski
Subject: Re: Branching vs Tagging for release candidates
Date: Tue, 07 Jul 2009 23:07:03 -0400
User-agent: Mutt/1.5.13 (2006-08-11)

On Tue, Jul 07, 2009 at 11:12:49AM -0400, Greg Akins spake thus:
> 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

Hi Greg,

A few possible alternate approaches:

After creating the branch that will become the release (6.1 above), you
could apply fixes to the branch first, and then to the trunk
(separately). It's double the work for applying a fix, but eliminates
the merge concerns; you'll never merge something unintended. It also
allows for similar but unique fixes on the two branches without worrying
about conflicts, but also introduces a decent possibility of human
error. Though I mention it here, I wouldn't really adopt this approach
in real life.

You could also introduce new features on individual branches, and when a
feature is deemed stable merge it into the trunk. With this approach,
whatever has already been merged to the trunk is "stable" and
"releaseable".  Minor bug fixes can be applied directly to trunk, and
when the release date comes, simply release it. With CVS, this approach
involves (IMHO) a bit too much overhead in the way of managing branches,
though; I would only adopt this approach if my team were strong users of
CVS in general and very comfortable with branching and merging, in

However, it seems that your work patterns more naturally fall into the
following scheme: you do all work on HEAD until nearing a release. At
some arbitrary point you declare the trunk "stable-ish" for release and
require any radical changes to happen on a branch (that tracks HEAD).
Bug fixes continue to be made on HEAD and automatically merged to the
branch(es). When you get to the point where the contents of HEAD are
what you want to consider a release, you tag it as such and make your
release. You then merge your radical dev branch(es) back into HEAD and
development continues on HEAD until you near the next release, at which
time you repeat the process.  The key points to this approach are:

    * The dev branches are made with the intent to merge them back into
      HEAD (so be sure to use merge point tags liberally).

    * Once the release is tagged on HEAD, a new branch starting at that
      tag should be used to apply any bug fixes to that release. This
      will require double application of the fixes once the release is
      made -- once on the branch created at the tag point, and once to
      HEAD; the details of such fixes may or may not be identical
      depending on how far HEAD has evolved from the code at the point
      of the release.

    * If there are no major features being added as you near a release,
      there will be no separate branches to merge back to the trunk; all
      stable features will have already been merged to the trunk.


a l a n   d.   s a l e w s k i             address@hidden
                        mail order bargins
                      self-cloning apparatus
                       fun for whole family
Generated from Haiku-O-Matic: 

reply via email to

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