From ced195a8556b68eab3dd0887e07a97c6ae4917bf Mon Sep 17 00:00:00 2001 From: Mathieu Lirzin Date: Wed, 6 Sep 2017 01:11:50 +0200 Subject: maint: Document new Branch names convention * HACKING: Update to new Branch names. --- HACKING | 32 ++++++++++++++------------------ 1 file changed, 14 insertions(+), 18 deletions(-) (limited to 'HACKING') 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". -- cgit v1.2.1