diff options
author | Mathieu Lirzin <mthl@gnu.org> | 2017-11-24 13:28:24 +0100 |
---|---|---|
committer | Mathieu Lirzin <mthl@gnu.org> | 2017-11-24 13:28:24 +0100 |
commit | 2e6c978a944eb57d49336b01a03dd6f9e573cd81 (patch) | |
tree | 8a43658ba7ee2788f3877cc39f548e01458c7965 | |
parent | 5e202df227d5f99801896995aee52992c119d7c8 (diff) | |
download | automake-2e6c978a944eb57d49336b01a03dd6f9e573cd81.tar.gz |
maint: Update HACKING
* HACKING (Working with git): Remove reference to the 'micro' branch and
adapt branch descriptions to the current branching scheme.
-rw-r--r-- | HACKING | 30 |
1 files changed, 12 insertions, 18 deletions
@@ -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. |