Re: GIT - releases workflow

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?

Sean

Hi,

On Tue, 12 Dec 2006, Sean Kelley wrote:

Why not just tag the release, and push the tag?

Hth, Dscho

Hi,

On Tue, 2006-12-12 at 23:54 +0100, Johannes Schindelin wrote:

I am doing both in my web SDK project.

I currently have two branches, master and maint/v1. Over time, if necessary, I'll open new branches named maint/v2, maint/v3 etc.

New development happens on master, bugfixes go to maint/v1 and get merged into master. If I do bugfix releases (2.0.x), I tag the tip of the maint/v1 branch.

I need a full branch, because I need the ability to do bugfixes for the already-released version.

Matthias

Hi,

On Wed, 13 Dec 2006, Matthias Kestenholz wrote:

Ah, that's right. I always forget that there are maintenance releases (mostly in Cathedral-ish projects)... I am not a release engineer during my day job, and I am just as happy about that.

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.

Ciao, Dscho

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

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.

Shawn Pearce <spearce@spearce.org> wrote:

[snip]

What I really should have said was the general idea here is that we never even have a trunk.

Developers work on topic branches and share/merge those individual branches as necessary to evolve a topic. When its suitably cooked in developer land it gets sent off to testing by being pushed into a someewhat descriptive ref under refs/heads/ready.

Testing can then accept topics by merging them together and creating tags via the described script.

Developers update their still cooking topic branches when necessary by pulling in the tags. git merge is smart enough to dereference the tag and generate the merge. Normally this is held off to the latest possible moment, and only to make sure there aren't any unexpected surprises from the merge waiting for the unsuspecting QA person.

Developers start new topic branches off the relevent tag they need to work on. New features are often made off the latest tag from QA; bug fixes are often off the tag currently in production.

So like I said, we're basically trunkless and happy. Tag happy. Thank you Linus, et.al. for packed refs!

Hi,

On 12/13/06, Matthias Kestenholz <lists@spinlock.ch> wrote:

That seems to match my use case.  So if I follow your description:

  git checkout -b maint/v0.1
  git pull . <remote project repo>
  git push origin maint/v0.1:maint/v0.1

Now the initial branch release is on the remote repo. So that my team can start hacking on the release branch. When we are ready, we need to create a release tag.

   git tag -a -m "Release 0.1.0" rel-v0.1.0

How do I push that tag that I created to the maint/v0.1 branch on the remote repository?

Thanks,

Sean

Hi,

On 12/13/06, Sean Kelley <sean.v.kelley@gmail.com> wrote:

Never mind, I answered my own question. Sorry for asking without doing my research first.

   git push --tags origin

Thanks,

Sean

Sean Kelley wrote:

Sort of, but not quite. This will push *all* your tags to wherever origin points to. If you, like me, use un-annotated tags to remember a particular snapshot you will then push a number of tags named "foo", "fnurg", "sdf" and "werwer" to the mothership repo.

	git push origin v0.1

works marvellously though.

Btw, this behaviour of mine, coupled with the company policy of only allowing annotated tags signed by the project maintainer as release-tags, lead to the creation of the update-hook I believe is still shipped as the default update-hook template with the git repo. It disallows un-annotated tags completely and should be used on the mothership repo.

On Tue, 12 Dec 2006, Sean Kelley wrote:

I don't think there is a "right" model, but at least _one_ model is what 
the kernel uses:
 - the actual "release" is just tagged
 - any release development (ie "maintenance") is literally done in a 
   totally separate repository, both from a development standpoint _and_ 
   an actual release management standpoint.

This may sound strange, but it actually has what I consider to be huge advantages:

 - it fits very well in the "distributed" mental model

 - it makes the separation of "maintenance" and "development" very very 
   clear. It's clear at all levels that the two are not the same thing, 
   don't have the same goals, and often not done by even the same groups, 
   or even by same management.

I think the second point is actually important.

At the same time, the distributed model of git means that if you want to mix the two trees, you easily can: you just fetch from the two independent release trees into the same repository. So the fact that they are maintained completely independently doesn't mean that they can't be joined, it just means that there's a clear separation at all levels.

Also note how _different_ releases may well end up having _separate_ repositories. So it's not that there is "one repository for development, and one repository for maintenance". It's literally "one repository for _each_ release maintenance".

Now, I think this kind of "separate repository for release maintenance trees" is actually a great model, and I think it can make perfect sense in various commercial/proprietary settings too (ie I know from experience that you tend to often have separate groups and very different rules for maintenance, so having the separate repository really does make sense).

But at the same time, for a smaller project, it obviously does NOT make sense. Git itself, for example, just has a "maint" branch, and does everything with the same maintainer, and in the same repository. Within something like git, that makes sense, because there just isn't a separate "stable tree maintainer", and trying to enforce that kind of thing would just be insane anyway within the setting of git.

So in some settings, you might just have a branch for each stable release, or as in the case of git, just a single branch for "maintenance", just because nobody is going to maintain older releases really at all (that might change with time, of course, but I think it's a pretty common pattern for smaller projects).

In short: I don't think there is "one correct way" to do these things.