doc/dev_guide: s/master/main in merging.rst

This changes the branch name "master" to the branch name
"main" in merging.rst.

Signed-off-by: Zac Dover <zac.dover@gmail.com>
This commit is contained in:
Zac Dover 2022-06-16 07:54:31 +10:00
parent f108f7de74
commit 52da71f0ab

View File

@ -18,10 +18,10 @@ What ?
Where ?
^^^^^^^
Features are merged to the *master* branch. Bug fixes should be merged to the
Features are merged to the *main* branch. Bug fixes should be merged to the
corresponding named branch (e.g. *nautilus* for 14.0.z, *pacific* for 16.0.z,
etc.). However, this is not mandatory - bug fixes and documentation
enhancements can be merged to the *master* branch as well, since the *master*
enhancements can be merged to the *main* branch as well, since the *main*
branch is itself occasionally merged to the named branch during the development
releases phase. In either case, if a bug fix is important it can also be
flagged for backport to one or more previous stable releases.
@ -32,16 +32,16 @@ When ?
After each stable release, candidate branches for previous releases enter
phase 2 (see below). For example: the *jewel* named branch was created when
the *infernalis* release candidates entered phase 2. From this point on,
*master* was no longer associated with *infernalis*. After he named branch of
the next stable release is created, *master* will be occasionally merged into
*main* was no longer associated with *infernalis*. After he named branch of
the next stable release is created, *main* will be occasionally merged into
it.
Branch merges
^^^^^^^^^^^^^
* The latest stable release branch is merged periodically into master.
* The master branch is merged periodically into the branch of the stable release.
* The master is merged into the stable release branch
* The latest stable release branch is merged periodically into main.
* The main branch is merged periodically into the branch of the stable release.
* The main is merged into the stable release branch
immediately after each development (x.0.z) release.
Stable release candidates (i.e. x.1.z) phase 1
@ -56,12 +56,12 @@ Where ?
^^^^^^^
The stable release branch (e.g. *jewel* for 10.0.z, *luminous*
for 12.0.z, etc.) or *master*. Bug fixes should be merged to the named
for 12.0.z, etc.) or *main*. Bug fixes should be merged to the named
branch corresponding to the stable release candidate (e.g. *jewel* for
10.1.z) or to *master*. During this phase, all commits to *master* will be
10.1.z) or to *main*. During this phase, all commits to *main* will be
merged to the named branch, and vice versa. In other words, it makes
no difference whether a commit is merged to the named branch or to
*master* - it will make it into the next release candidate either way.
*main* - it will make it into the next release candidate either way.
When ?
^^^^^^
@ -72,9 +72,9 @@ x.1.0 tag is set in the release branch.
Branch merges
^^^^^^^^^^^^^
* The stable release branch is merged periodically into *master*.
* The *master* branch is merged periodically into the stable release branch.
* The *master* branch is merged into the stable release branch
* The stable release branch is merged periodically into *main*.
* The *main* branch is merged periodically into the stable release branch.
* The *main* branch is merged into the stable release branch
immediately after each x.1.z release candidate.
Stable release candidates (i.e. x.1.z) phase 2
@ -90,7 +90,7 @@ Where ?
The stable release branch (e.g. *mimic* for 13.0.z, *octopus* for 15.0.z
,etc.). During this phase, all commits to the named branch will be merged into
*master*. Cherry-picking to the named branch during release candidate phase 2
*main*. Cherry-picking to the named branch during release candidate phase 2
is performed manually since the official backporting process begins only when
the release is pronounced "stable".
@ -102,7 +102,7 @@ After Sage Weil announces that it is time for phase 2 to happen.
Branch merges
^^^^^^^^^^^^^
* The stable release branch is occasionally merged into master.
* The stable release branch is occasionally merged into main.
Stable releases (i.e. x.2.z)
----------------------------
@ -112,8 +112,8 @@ What ?
* Bug fixes
* Features are sometime accepted
* Commits should be cherry-picked from *master* when possible
* Commits that are not cherry-picked from *master* must pertain to a bug unique to
* Commits should be cherry-picked from *main* when possible
* Commits that are not cherry-picked from *main* must pertain to a bug unique to
the stable release
* See also the `backport HOWTO`_ document