I want to preface this by noting that I think this is really much ado
about nothing. I've done these sorts of non-rewindable branch renamings
before, and while they're mildly annoying, it's pretty rare that there are
tons of people out there with Git clones that aren't following the
development mailing list and get somehow confused. It's just not that big
of a deal; basically everyone who has bothered to clone your Git
repository for the typical smallish project (and Automake, despite being
very widely used, is from a development perspective a smallish project) is
following the mailing list anyway and will see the instructions.
Also, those of us who have been using Git for a while will have run into
this before and will have some idea of how to deal with it. And, failing
that, even if one can't figure out the right way to manipulate one's local
repository to prepare, there's always the hammer approach of git
format-patch to generate whatever local changes one has, cloning a new
repository, and git am to put them back, which really isn't that big of a
deal.
Therefore, I think whoever is active in development should basically just
do whatever they want to do and the rest of us will cope. I think it's
way more important that the primary developers be comfortable with the
setup (and not feel demotivated by having to argue about it) than any
particular scheme of Git purity be adopted.
That said, if and only if the folks who are mostly doing the work are
interested in the more theoretical discussion of possible schemes....
Miles Bader <mi...@gnu.org> writes:
> Stefano Lattarini <stefano.lattar...@gmail.com> writes:
>> So we should maybe go (after the next major release) with this naming
>> scheme for the branches?
>>
>> * maint -> for next micro version
>> * stable -> for next minor version
>> * master -> for next major version
> That seems to match common practice, insofar as I understand it...
> [Another consideration is whether you have a single named branch for
> maintenance (e.g. "maint", and "stable"), or just use version-named
> branches (and thus can maintain multiple versions simultaneously).]
I'd say that the latter (using separate branches for each version) is the
most common. One other advantage is that if you don't have any changes
that need to be restricted to a particular scope, you don't bother
creating the branch.
So, you start with just:
master -> for next major version
plus of course tags for each release.
At the point at which you have a change that should go into the next minor
version and a change that should *not* go into the next minor version (in
other words, at the point at which the maintenance diverges), you create a
new branch:
stable-2 (for maintenance of version 2.* for example)
make the change on that branch and merge that branch to master. (Or make
the change on master and cherry-pick it to the branch, but it's always
nice to merge the stable branch onto master to be sure you didn't miss
anything.)
Since it's quite likely that you'll want this level of branching, it's of
course reasonable to make this branch proactively.
You make minor and micro releases for version 2.* from that branch up
until the point at which there's something that needs to go into the micro
release and other changes that shouldn't, at which point you might create:
stable-2.1 (for example)
to manage further 2.1.* micro releases.
Many projects never need that last level of branching. I suspect you'll
find that you will use it once or twice but not as a systematic practice.
Usually, it's easier to just make releases from the stable branch and
version them (either minor or micro) according to the nature of the
changes that have accumulated.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
