On 04/04/2012 01:38 PM, Stefano Lattarini wrote:
> On 04/04/2012 12:55 PM, Peter Rosin wrote:
>
>> Ok, we'll have to agree to disagree then.
>>
> That's fine, I just wanted to be sure there were no misunderstandings nor
> incomprehension.
>
I've pushed the attached patch to 'master' now. I will wait to close this
report until Automake 1.12 is released and the new branching/merging policy
is in place though.
Regards,
Stefano
>From 678de655e93ef9136281f8aa792f3722d12a740f Mon Sep 17 00:00:00 2001
Message-Id: <678de655e93ef9136281f8aa792f3722d12a740f.1334159107.git.stefano.lattar...@gmail.com>
From: Stefano Lattarini <stefano.lattar...@gmail.com>
Date: Mon, 2 Apr 2012 18:16:38 +0200
Subject: [PATCH] hacking: described new branching policy for 1.12 an later
This change closes automake bug#11153.
* HACKING (Working with git): Document the new policy for automake
branching and merging, which will start being applied after 1.12 is
released:
- the maintenance branch will be 'maint', and we will cut the
maintenance releases directly from there;
- the development branch will be 'master', and we will cut the
new releases directly from there;
- 'maint' will be kept regularly merged into 'master'.
Signed-off-by: Stefano Lattarini <stefano.lattar...@gmail.com>
---
HACKING | 53 ++++++++++++++++-------------------------------------
1 files changed, 16 insertions(+), 37 deletions(-)
diff --git a/HACKING b/HACKING
index 29c0e4a..8d3471f 100644
--- a/HACKING
+++ b/HACKING
@@ -103,37 +103,22 @@
latest stable version of Autoconf installed and available early
in your PATH.
-* The git tree currently carries a number of branches: master for the
- current development, and release branches named branch-X.Y. The maint
- branch serves as common ground for both master and the active release
- branches. Changes intended for both should be applied to maint, which
- should then be merged to release branches and master, of course after
- suitable testing. It is advisable to merge only after a set of related
- commits have been applied.
-
-* Example work flow for patches to maint:
-
- # 1. Checkout the "maint" branch:
- git checkout maint
-
- # 2. Apply the patch(es) with "git am" (or create them with $EDITOR):
- git am -3 0*.patch
- # 2a. Run required tests, if any ...
-
- # 3. Merge maint into branch-1.11:
- git checkout branch-1.11
- git merge maint
- # 3a. Run required tests, if any ...
-
- # 4. Redo steps 3 and 3a for master:
- git checkout master
- git merge maint
- # testing ...
-
- # 5. Push the maint and master branches:
- git push --dry-run origin maint branch-1.11 master
- # if all seems ok, then actually push:
- git push origin maint branch-1.11 master
+* 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 yet be ready for master.
+
+* After a major release is done, 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.
--
1.7.9
