maint: Document new Branch names convention

* HACKING: Update to new Branch names.

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".