diff options
author | Stefano Lattarini <stefano.lattarini@gmail.com> | 2012-04-02 18:16:38 +0200 |
---|---|---|
committer | Stefano Lattarini <stefano.lattarini@gmail.com> | 2012-04-11 17:48:12 +0200 |
commit | 0d0cafcdcae41ce4d4018448d3f5d95f815111a8 (patch) | |
tree | e40c967a8ac07ce7e7a685f99b8476210d4eff09 /HACKING | |
parent | 3d5d5eace287c0aad4a1e9221dcebc62e2a886ee (diff) | |
download | automake-0d0cafcdcae41ce4d4018448d3f5d95f815111a8.tar.gz |
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.lattarini@gmail.com>
Diffstat (limited to 'HACKING')
-rw-r--r-- | HACKING | 53 |
1 files changed, 16 insertions, 37 deletions
@@ -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. |