Re: GIT - releases workflow

From: Shawn Pearce <spearce@spearce.org>
Date: Dec 13, 2006, 10:56 UTC
Message-ID: <20061213105614.GB9484@spearce.org>
In-Reply-To: <Pine.LNX.4.63.0612131133160.3635@wbgn013.biozentrum.uni-wuerzburg.de>

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 10 quoted lines

> > > On Tue, 12 Dec 2006, Sean Kelley wrote:
> > > 
> > > > I was wondering if anyone could share ideas on how best to use GIT to 
> > > > handle releases for those working with a remote GIT repository?  Do you 
> > > > create a branch and push it to the remote?  Thus you have a new branch 
> > > > referencing the particular release?
> 
> BTW, if the maintenance releases are sparse and long between, you can 
> actually create the branch from the tag, fix, and tag with the new version 
> number. No need to start the branches early.

Indeed.

I actually have a fancy (==~800 poorly written lines) Perl script that:

 * Creates a "build" git repository using objects/info/alternates.
   The user can reuse an existing directory if they have one.
   (Obviously reusing an existing directory is faster, less files
   to setup in the working directory.)

 * Offers the user a menu of top 10 most recent tags to choose as
   a base version.  Tags are displayed first sorted by which tag
   is considered to be in which runtime environment (QA testing,
   end user testing, production release), then by tag date for
   those tags not in any specific environment.

 * Offers the user a menu of branches in a pre-configured namespace
   (e.g. refs/heads/ready) which have commits not yet merged into
   the selected base.  Users can attempt to pull as many branches
   as they like, the script merges each in turn until none remain
   or the user says "build!".

 * Increments the last component of the 'version number' of the tag
   and makes an annotated tag object in the local build repository.

 * Runs the project's configured build command (from repo-config
   taken from builder.command variable).

 * If builder.command is successful pushes the tag back to the origin
   repository; if builder.command fails pushes the HEAD revision
   up as a branch (e.g. refs/heads/failed/foo) so that someone more
   skilled in the art of failed builds can look into the matter.

The script is really meant for QA people to take in topic branches from developers and apply them to a specific version, test that new version, then ship that new version. Some of the QA people I work with aren't developers and have a somewhat difficult time making a build from source; this script makes it a pretty simple process.

The version number incrementor is smart; its based off commit lineage. It can automatically create a "2.0.1" tag when "2.1" has already been made but "2.0.1" is a bugfix of "2" or "2.0".

I should clean it up some and post it, just in case others may be interested. I'll try to do that this weekend.