GIT - releases workflow

GIT - releases workflow

[Sean Kelley]

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

-- 

Re: GIT - releases workflow

[Johannes Schindelin]

Hi,

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?

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

Hth,
Dscho

Re: GIT - releases workflow

[Matthias Kestenholz]

Hi,

On Tue, 2006-12-12 at 23:54 +0100, Johannes Schindelin wrote:
> Hi,
> 
> 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?
> 
> Why not just tag the release, and push the tag?

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

Re: GIT - releases workflow

[Johannes Schindelin]

Hi,

On Wed, 13 Dec 2006, Matthias Kestenholz wrote:

> On Tue, 2006-12-12 at 23:54 +0100, Johannes Schindelin wrote:
> > 
> > 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?
> > 
> > Why not just tag the release, and push the tag?
> 
> 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.

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

Re: GIT - releases workflow

[Shawn Pearce]

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > 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.

-- 

Re: GIT - releases workflow

[Shawn Pearce]

Shawn Pearce <spearce@spearce.org> wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > > 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.
[snip]
> 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".

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!

-- 

Re: GIT - releases workflow

[Sean Kelley]

Hi,

On 12/13/06, Matthias Kestenholz <lists@spinlock.ch> wrote:
> Hi,
>
> On Tue, 2006-12-12 at 23:54 +0100, Johannes Schindelin wrote:
> > Hi,
> >
> > 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?
> >
> > Why not just tag the release, and push the tag?
>
> 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.


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


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


-- 

Re: GIT - releases workflow

[Sean Kelley]

Hi,

On 12/13/06, Sean Kelley <sean.v.kelley@gmail.com> wrote:
> Hi,
>
> On 12/13/06, Matthias Kestenholz <lists@spinlock.ch> wrote:
> >
> How do I push that tag that I created to the maint/v0.1 branch on the
> remote repository?

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

   git push --tags origin

Thanks,

Sean
>
> Thanks,
>
> Sean
>
>
> >
> > I need a full branch, because I need the ability to do bugfixes for the
> > already-released version.
> >
> > Matthias
> >
> >
>
>
> --
> Sean Kelley
>


-- 

Re: GIT - releases workflow

[Andreas Ericsson]

Sean Kelley wrote:
> Hi,
> 
> On 12/13/06, Sean Kelley <sean.v.kelley@gmail.com> wrote:
>> Hi,
>>
>> On 12/13/06, Matthias Kestenholz <lists@spinlock.ch> wrote:
>> >
>> How do I push that tag that I created to the maint/v0.1 branch on the
>> remote repository?
> 
> Never mind, I answered my own question.  Sorry for asking without
> doing my research first.
> 
>   git push --tags origin
> 

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.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se

Re: GIT - releases workflow

[Linus Torvalds]

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?

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.