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.
Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
