Re: change automake branching policy: dispensing with the 'branch-X.Y' branches in the future

[Jim Meyering]

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.