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/>