* GIT - releases workflow
@ 2006-12-12 22:44 Sean Kelley
2006-12-12 22:54 ` Johannes Schindelin
2006-12-13 2:43 ` Linus Torvalds
0 siblings, 2 replies; 10+ messages in thread
From: Sean Kelley @ 2006-12-12 22:44 UTC (permalink / raw)
To: git
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
--
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GIT - releases workflow
2006-12-12 22:44 GIT - releases workflow Sean Kelley
@ 2006-12-12 22:54 ` Johannes Schindelin
2006-12-13 9:10 ` Matthias Kestenholz
2006-12-13 2:43 ` Linus Torvalds
1 sibling, 1 reply; 10+ messages in thread
From: Johannes Schindelin @ 2006-12-12 22:54 UTC (permalink / raw)
To: Sean Kelley; +Cc: git
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GIT - releases workflow
2006-12-12 22:44 GIT - releases workflow Sean Kelley
2006-12-12 22:54 ` Johannes Schindelin
@ 2006-12-13 2:43 ` Linus Torvalds
1 sibling, 0 replies; 10+ messages in thread
From: Linus Torvalds @ 2006-12-13 2:43 UTC (permalink / raw)
To: Sean Kelley; +Cc: git
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GIT - releases workflow
2006-12-12 22:54 ` Johannes Schindelin
@ 2006-12-13 9:10 ` Matthias Kestenholz
2006-12-13 10:36 ` Johannes Schindelin
2006-12-13 12:34 ` Sean Kelley
0 siblings, 2 replies; 10+ messages in thread
From: Matthias Kestenholz @ 2006-12-13 9:10 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Sean Kelley, git
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GIT - releases workflow
2006-12-13 9:10 ` Matthias Kestenholz
@ 2006-12-13 10:36 ` Johannes Schindelin
2006-12-13 10:56 ` Shawn Pearce
2006-12-13 12:34 ` Sean Kelley
1 sibling, 1 reply; 10+ messages in thread
From: Johannes Schindelin @ 2006-12-13 10:36 UTC (permalink / raw)
To: Matthias Kestenholz; +Cc: Sean Kelley, git
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GIT - releases workflow
2006-12-13 10:36 ` Johannes Schindelin
@ 2006-12-13 10:56 ` Shawn Pearce
2006-12-13 11:14 ` Shawn Pearce
0 siblings, 1 reply; 10+ messages in thread
From: Shawn Pearce @ 2006-12-13 10:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Matthias Kestenholz, Sean Kelley, git
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.
--
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GIT - releases workflow
2006-12-13 10:56 ` Shawn Pearce
@ 2006-12-13 11:14 ` Shawn Pearce
0 siblings, 0 replies; 10+ messages in thread
From: Shawn Pearce @ 2006-12-13 11:14 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Matthias Kestenholz, Sean Kelley, git
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!
--
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GIT - releases workflow
2006-12-13 9:10 ` Matthias Kestenholz
2006-12-13 10:36 ` Johannes Schindelin
@ 2006-12-13 12:34 ` Sean Kelley
2006-12-13 12:39 ` Sean Kelley
1 sibling, 1 reply; 10+ messages in thread
From: Sean Kelley @ 2006-12-13 12:34 UTC (permalink / raw)
To: Matthias Kestenholz; +Cc: git
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
>
>
--
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GIT - releases workflow
2006-12-13 12:34 ` Sean Kelley
@ 2006-12-13 12:39 ` Sean Kelley
2006-12-13 13:13 ` Andreas Ericsson
0 siblings, 1 reply; 10+ messages in thread
From: Sean Kelley @ 2006-12-13 12:39 UTC (permalink / raw)
To: Matthias Kestenholz; +Cc: git
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
>
--
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GIT - releases workflow
2006-12-13 12:39 ` Sean Kelley
@ 2006-12-13 13:13 ` Andreas Ericsson
0 siblings, 0 replies; 10+ messages in thread
From: Andreas Ericsson @ 2006-12-13 13:13 UTC (permalink / raw)
To: Sean Kelley; +Cc: Matthias Kestenholz, git
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
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2006-12-13 13:13 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-12-12 22:44 GIT - releases workflow Sean Kelley
2006-12-12 22:54 ` Johannes Schindelin
2006-12-13 9:10 ` Matthias Kestenholz
2006-12-13 10:36 ` Johannes Schindelin
2006-12-13 10:56 ` Shawn Pearce
2006-12-13 11:14 ` Shawn Pearce
2006-12-13 12:34 ` Sean Kelley
2006-12-13 12:39 ` Sean Kelley
2006-12-13 13:13 ` Andreas Ericsson
2006-12-13 2:43 ` Linus Torvalds
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).