Mathieu Lirzin <m...@gnu.org> writes: > Indeed HACKING is not up-to-date, I will fix that.
Here is a patch that should help describing the new branching model more accurately. If you see further improvements or would prefer different wording, tell me.
>From 2e6c978a944eb57d49336b01a03dd6f9e573cd81 Mon Sep 17 00:00:00 2001 From: Mathieu Lirzin <m...@gnu.org> Date: Fri, 24 Nov 2017 13:28:24 +0100 Subject: [PATCH] maint: Update HACKING * HACKING (Working with git): Remove reference to the 'micro' branch and adapt branch descriptions to the current branching scheme. --- HACKING | 30 ++++++++++++------------------ 1 file changed, 12 insertions(+), 18 deletions(-) diff --git a/HACKING b/HACKING index 8e7764b..ded1c7f 100644 --- a/HACKING +++ b/HACKING @@ -156,15 +156,8 @@ latest stable version of Autoconf installed and available early in your PATH. -* The Automake git tree currently carries three basic branches: 'micro', - 'maint' and 'master'. - -* 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 Automake git tree currently carries three basic branches: 'master', + 'next' and 'maint'. * The 'master' branch is where the development of the next release takes place. It should be kept in a stable, almost-releasable state, @@ -172,6 +165,16 @@ this is not a hard rule, and such "stability" is not expected to be absolute (emergency releases are cut from the 'maint' branch anyway). +* When planning a release a dedicated branch should be created and after + the release is done, the release branch is to be merged both into the + 'master' branch and the 'maint' branch. + +* Besides merges from release branches, the 'maint' branch can contain + fixes for regressions, trivial bugs, or documentation issues, that + will be part of an emergency regression-fixing or security releases. + As a consequence it should always be kept in a releasable state and no + "active" development should be done whatsoever. + * 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 @@ -187,15 +190,6 @@ 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 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 - introduced the bug. Then this "bugfix branch" can be merged into all - the active branches descending from the buggy commit. This offers a - simple way to fix the bug consistently and effectively. - * When merging, 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. -- 2.9.5
-- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
