Re: GIT - releases workflow

[Linus Torvalds <torvalds@osdl.org>]

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.