Stefano Lattarini wrote: ... > WDYT? If you agree, I can apply the change below to HACKING, and > implement the new branching policy starting from the Automke 1.12 > release.
I agree. IMHO, you won't go wrong following git.git's example. > diff --git a/HACKING b/HACKING ... > +* The Automake git tree currently carries two basic branches: 'master' for > + the current development, and 'maint' for maintenance and bug fixes. The > + maint branch should be kept regularly merged into the master branch. > + It is advisable to merge only after a set of related commits have been > + applied, to avoid introducing too much noise in the history. > + > +* There may be a number of longer-lived feature branches for new > + developments. They should be based off of a common ancestor of all > + active branches to which the feature should or might be merged later. > + in the future, we might introduce a special branch named 'next' that > + may serve as common ground for feature merging and testing, should > + they not be ready for master yet. reorder slightly: they not yet be ready for master. > +* When a major release is done, the master branch is to be merged into Does this convey your meaning? After making a major release, the master branch is to be merged into > + the maint branch, and then a "new" master branch created stemming > + from the resulting commit. > > * When fixing a bug (especially a long-standing one), it may be useful > to commit the fix to a new temporary branch based off the commit that > @@ -141,12 +126,6 @@ > the active branches descending from the buggy commit. This offers a > simple way to fix the bug consistently and effectively. > > -* There may be a number of longer-lived feature branches for new > developments. > - They should be based off of a common ancestor of all active branches to > - which the feature should or might be merged later. The next branch may > - serve as common ground for feature merging and testing, should they not > - be ready for master yet. > - > * For merges from branches other than maint, prefer 'git merge --log' over > plain 'git merge', so that a later 'git log' gives an indication of which > actual patches were merged even when they don't appear early in the list.