[Top][All Lists]

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

Re: building a release: branching or tagging

From: david
Subject: Re: building a release: branching or tagging
Date: Tue, 11 Jun 2002 09:44:52 -0500 (CDT)

> 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?
What do you mean by "incremental release"?  It sounds to me like a release
from a development effort that keeps going.  In this case, it depends
on what you intend to do with it.  If the idea is to throw it out there
for user examination, then it's less important than if you intend to
have customers use it for some time.

Our practice was to cut a branch for each release, make bugfixes where
relevant, and merge them to appropriate branches.
> 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?
This implies that the release, once shipped, will never be changed.
If there are going to be any changes, you'll need a branch to avoid
including later changes, which may be unready, or not what that
customer wants, or simply functionality you don't want to send with
this release.
> 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?  
Here's how we did it.

The trunk was for main development.  Periodically (ideally every six
months, but this tended to slip) we would cut a release branch.  At
that time, new functionality was supposed to stop, although it's really
not possible to time things so all the new functionality is ready at
the same time, so there was generally work going on after the branch
cut (while other people, who had finished their pieces for the release
earlier, were working on next release's functionality on the trunk).

When changes were made in the release, they were merged to the trunk.
These included finishing up new functionality and bugfixes.  While we
did continuous testing, it was by no means perfect, and there were
bugs that were best eradicated in an environment with no new
> 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?
One branch per release.  This also allowed us to support customers with
previous releases (unfortunately necessary for us).

David H. Thornley                        | If you want my opinion, ask.
address@hidden                       | If you don't, flee. | O-

reply via email to

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