Now that I got your attention, here are some observations and thoughts
about our development model for git.git. In fact I think we have a
successful model (and a great maintainer) but there is always room for
improvement.
The sacred cow from the subject line is backwards compatibility, and it
is sacred for a good reason. People can happily run git.git's master or
even next without too many surprises as long as they're on their watch
for some slightly larger changes in 1.x.0 releases. Distros choose to
follow maint or master.
Still, lately several discussions here have put me in a slaughterous
mood so to say. Our code base is "naturally grown", and as much as I
like that for a garden, it basically makes any attempts at providing a
consistent and smooth sur^Winterface impossible, because this always
requires some cuts. So, why not let the cow do the greenkeeping to get
the ball rolling smoothly again ;)
I think the technical reason behind this issue is the short-livedness of
our topic branches and pu. Who's looking at any 10+ patch series? I
mean, it was always easy to, say,
git merge $(git rev-parse ":/Merge branch
'mg/rev-parse-lrbranches-locals")^2
for stuff on pu and this is even easier now with the topic branches
pushed out by Junio to github. But large series simply get over-grown.
We don't have a place like kernel-next for large structural incompatible
changes. Our "next" is a very stable branch with what will be the next
small increments on master, and it serves a very good purpose.
Shortly before an upcoming 1.x.0 we often have "for-1.x.0"-topics but I
don't think that can house large developments like
- consistent interface for subcommands ("branch --setupstream" vs.
"remote add" etc.),
- consistent approach on DWImery (may require removing some, or making
it dependent on config),
- consistent treatment of porcelain/plumbing hermaphrodites (may require
breaking some assumptuous scripts).
Those are just a few examples of issues which are confusing for new
users, which are there just because they grew to be there (or because of
implementation details), and which don't go away because of that cow.
I don't pretend to have a perfect solution for this, but I'm wondering
whether a longer-lived for-1.x.0 branch (with or without an extra pu,
i.e. not rewinding itself [leaving that for the extra pu] or rewinding)
would be feasible which gets everything from next-master-maint and which
would also be a place to cook larger structural, backwards incompatible
changes. An alternative would be to have a branch like that for a
specific large topic (like one of the above) and focus on that for the
upcoming release.
The idea behind all this is that it would allow to work on a large topic
(breaking compatibility) early on, right after a 1.x.0 (which is
impossible right now), and hopefully have it exposed to more people,
maybe providing an integration branch if we go with the "long lived
large topic branch" approach rather then the first one described above.
As time goes by the cow can do her thing, and people can be aware of
upcoming changes much earlier. Then it should be alright to break a few
more scripts in a 1.x.0 release - we always broke a few, so people would
always have to check before switching anyways.
Cheers,
Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html