Re: building a release: branching or tagging

[Rob Helmer]

Hello Edward,


On Mon, Jun 10, 2002 at 07:42:37PM -0500, Edward Dunkle wrote:
> please excuse if this is a double post.  It seems earlier posts have failed.
> 
> What is the recommneded practise for building an incremental release without
> pulling  in incomplete code changes in the main trunk?
> 
> Some have suggested that we never branch and merge but simply tag individual
> files associated with each implemented change to be included in the next
> release so that each of these may be pulled specifically.  Do you see any
> issues with this approach?
> 
> The docs seem to describe branching and merging as an approach to use.  Are
> people successful with this?  
> 
> DO you make releases off a branch and then merge it into the trunk and then
> make another branch for the next release?  
> 
> Do you make one branch for each release or branch and merge for each change
> request that is to be included in the next release?

Personally, I branch for releases. Changes that are applicable to both
the branch and trunk are checked into the trunk and moved to the branch
by the build/release engineer (me), and changes that are only applicable
to the branch are made directly to the branch.

I think that merging is great, but I don't think it's ok to do blind
merges back and forth without making sure the code is still doing 
what you want it to do. Especially when you get into conflict situations.

If there have been tons of system-wide changes on the trunk, you
need to intelligently remove things on the branch and move them
from the trunk. This is usually the kind of situation you want
to do a new release for, not really a "patch".

If it's just a "patch" release for a bugfix, then it's pretty
easy to move individual files from the trunk to the branch by
hand, or make changes directly to the branch if the patch is
no longer applicable to the trunk.

I usually don't merge between the trunk and the branch, just copy.
This is just a personal preference, I think copying is easier, and
keeps the trunk and branch versions in closer sync, and makes it
easier when looking at version history to see what happened ( rather
than two checkin comments that say "fixed rollover bug" in two different
ways, you see one "fixed rollover bug" on the trunk and "copied rollover
bug from r1.4 from the trunk" on the branch revision ).
Again, personal preference.

This depends alot on your product and your release cycle, of course.
I usually look at releases as "frozen", you only want to update a
branch in order to fix bugs.

If you *need* to add a feature to both the release and the current
development ( which I discourage ), or fix a very deep bug, it is done as
above, carefully by someone who has some understanding of what
they are doing, and access to the developers who made the original
change ( or maybe by the developers themselves ).

I don't see any reason to ever merge from the branch back to trunk,
that just doesn't make sense to me. The trunk is always aiming at
the next release, but you keep branches in case you need to patch
previous releases that customers are on. 

If your development process doesn't work like this, you'll probably
need to figure something else out. In general, I favor generic code
that is configurable enough to deliver to multiple users, rather
than having a branch for each of my customers. These kinds of things 
heavily influence your use of any version control system.



HTH,
Rob