GNU bug report logs - #11153
change automake branching policy: dispensing with the 'branch-X.Y' branches in the future

Previous Next

Full log

Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: bug-automake <at> gnu.org, "automake-patches <at> gnu.org" <automake-patches <at> gnu.org>
Subject: Re: change automake branching policy: dispensing with the
	'branch-X.Y' branches in the future
Date: Mon, 02 Apr 2012 20:47:16 +0200

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.