[Top][All Lists]

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

Re: building a release: branching or tagging

From: Karl E. Jorgensen
Subject: Re: building a release: branching or tagging
Date: Tue, 11 Jun 2002 16:52:09 +0100
User-agent: Mutt/1.3.25i

On Tue, Jun 11, 2002 at 09:44:52AM -0500, address@hidden wrote:
> > 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
> functionality.
> > 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).

A small addition: 

For some changes, it may be useful to create a "project" branch where
all the work relating to a specific change can be done, without
destabilising the trunc. This is useful when e.g.:

- The change is non-trivial and is expected to destabilise the trunc for
  a while. 

- If you're not certain that the change will be complete before the next
  release is branched off the trunc. Otherwise you will have to
     a) selectively revert out changes to remove all traces of the
        incomplete change
  or b) release *with* the incomplete change
  or c) delay the release
  All 3 of which are usually worth avoiding...

- If you do NOT want the change to be part of the next release. Then you
  don't want it on the trunc (yet).

- Multiple developers are involved in the change.

- If you think the users may change their mind and not want the change
  after all (yes: it happens) or the business priorities change and they
  want something else to be released first. Since the changes aren't on
  the trunc, it's easy to declare the branch "dead" and possible
  resurrect it later.

- There is doubt about *how* to implement it. (But then you really
  shouldn't start changing code yet, or at least not let the code leave
  the sandbox). Multiple branches allow you to try out competing
  implementations, without messing things up (too much)

The downside is of course that the project branch will have to be merged
into the trunc (and the possible conflicts that may arise from that).

Just my 2p...
Karl E. Jørgensen
==== Today's fortune:
Sex, Drugs & Linux Rules
        -- MaDsen Wikholm, address@hidden

reply via email to

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