summaryrefslogtreecommitdiff
path: root/HACKING
diff options
context:
space:
mode:
authorMathieu Lirzin <mthl@gnu.org>2017-09-06 01:11:50 +0200
committerMathieu Lirzin <mthl@gnu.org>2017-09-19 13:55:48 +0200
commitced195a8556b68eab3dd0887e07a97c6ae4917bf (patch)
tree2938ba28267cfc6d6cba0b763f80e4b32ce49b03 /HACKING
parent1b3b7b7d25a0762b7cc9ca8a62da559a42a2e844 (diff)
downloadautomake-ced195a8556b68eab3dd0887e07a97c6ae4917bf.tar.gz
maint: Document new Branch names convention
* HACKING: Update to new Branch names.
Diffstat (limited to 'HACKING')
-rw-r--r--HACKING32
1 files changed, 14 insertions, 18 deletions
diff --git a/HACKING b/HACKING
index 21dab2a74..a603b6953 100644
--- a/HACKING
+++ b/HACKING
@@ -159,40 +159,36 @@
* The Automake git tree currently carries three basic branches: 'micro',
'maint' and 'master'.
-* The 'micro' branch, reserved to changes that should go into the next
+* The 'maint' branch, reserved to changes that should go into the next
micro release; so it will just see fixes for regressions, trivial
bugs, or documentation issues, and no "active" development whatsoever.
Since emergency regression-fixing or security releases could be cut
from this branch at any time, it should always be kept in a releasable
state.
-* The 'maint' branch is where the development of the next minor release
+* The 'master' branch is where the development of the next release
takes place. It should be kept in a stable, almost-releasable state,
to simplify testing and deploying of new minor version. Note that
this is not a hard rule, and such "stability" is not expected to be
- absolute (emergency releases are cut from the 'micro' branch anyway).
+ absolute (emergency releases are cut from the 'maint' branch anyway).
-* The 'master' branch is reserved for the development of the next major
+* The 'next' branch is reserved for the development of the next major
release. Experimenting a little is OK here, but don't let the branch
grow too unstable; if you need to do exploratory programming or
over-arching change, you should use a dedicated topic branch, and
only merge that back once it is reasonably stable.
-* The 'micro' branch should be kept regularly merged into the 'maint'
- branch, and the 'maint' branch 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.
+* The 'next' 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.
-* After a new minor release is done, the 'maint' branch is to be merged
- into the 'micro' branch, and then a "new" 'maint' branch created
- stemming from the resulting commit.
- Similarly, after a new major release is done, the 'master' branch is to
- be merged into both the 'micro' and 'maint' branches, and then "new"
- 'master' branch created stemming from the resulting commit.
+* After a release is done, the release branch is to be merged both
+ into the 'master' branch and the 'maint' branch.
* 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
@@ -204,10 +200,10 @@
a later 'git log' gives an indication of which actual patches were
merged even when they don't appear early in the list.
-* The 'master', 'maint' and 'micro' branches should not be rewound, i.e.,
- should always fast-forward, except maybe for privacy issues. For
- feature branches, the announcement for the branch should document
- the rewinding policy.
+* The 'master', 'maint' and 'next' branches should not be rewound,
+ i.e., should always fast-forward, except maybe for privacy issues.
+ For feature branches, the announcement for the branch should
+ document the rewinding policy.
If a topic branch is expected to be rewound, it is good practice to put
it in the 'experimental/*' namespace; for example, a rewindable branch
dealing with Vala support could be named like "experimental/vala-work".