-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Update references to master to point to main (#1948)
- Loading branch information
Showing
1 changed file
with
22 additions
and
22 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -96,11 +96,11 @@ There are several types of releases you will need to make. These include: | |
Some of these release types actually involve more than | ||
one release branch. In particular, a **new branch** is that point in the | ||
release cycle when a new feature release cycle begins. Under the current | ||
organization of the cpython git repository, the *master* branch is always | ||
organization of the cpython git repository, the *main* branch is always | ||
the target for new features. At some point in the release cycle of the | ||
next feature release, a **new branch** release is made which creates a | ||
new separate branch for stabilization and later maintenance of the | ||
current in-progress feature release (x.y.0) and the *master* branch is modified | ||
current in-progress feature release (x.y.0) and the *main* branch is modified | ||
to build a new version (which will eventually be released as x.y+1.0). | ||
While the **new branch** release step could occur at one of several points | ||
in the release cycle, current practice is for it to occur at feature code | ||
|
@@ -247,8 +247,8 @@ to perform some manual editing steps. | |
if there are differences, commit them. | ||
|
||
- Make sure the ``SOURCE_URI`` in ``Doc/tools/extensions/pyspecific.py`` | ||
points to the right branch in the git repository (``master`` or ``X.Y``). | ||
For a **new branch** release, change the branch in the file from *master* | ||
points to the right branch in the git repository (``main`` or ``X.Y``). | ||
For a **new branch** release, change the branch in the file from *main* | ||
to the new release branch you are about to create (``X.Y``). | ||
|
||
- Bump version numbers via the release script:: | ||
|
@@ -502,8 +502,8 @@ the main repo. | |
# Checkout the correct branch: | ||
# 1. For feature pre-releases up to and including a | ||
# **new branch** release, i.e. alphas and first beta | ||
# do a checkout of the master branch | ||
$ git checkout master | ||
# do a checkout of the main branch | ||
$ git checkout main | ||
|
||
# 2. Else, for all other releases, checkout the | ||
# appropriate release branch. | ||
|
@@ -522,7 +522,7 @@ the main repo. | |
|
||
Do any steps needed to setup the new release branch, including: | ||
|
||
* In README.rst, change all references from ``master`` to | ||
* In README.rst, change all references from ``main`` to | ||
the new branch, in particular, GitHub repo URLs. | ||
|
||
- For *all* releases, do the guided post-release steps with the | ||
|
@@ -550,13 +550,13 @@ the main repo. | |
$ git commit -m 'Post release updates' | ||
|
||
- If this is a **new branch** release (e.g. the first beta), | ||
update the master branch to start development for the | ||
following feature release. When finished, the ``master`` | ||
update the main branch to start development for the | ||
following feature release. When finished, the ``main`` | ||
branch will now build Python ``X.Y+1``. | ||
|
||
- First, set master up to be the next release, i.e.X.Y+1.a0:: | ||
- First, set main up to be the next release, i.e.X.Y+1.a0:: | ||
|
||
$ git checkout master | ||
$ git checkout main | ||
$ .../release-tools/release.py --bump 3.9.0a0 | ||
|
||
- Edit all version references in README.rst | ||
|
@@ -584,7 +584,7 @@ the main repo. | |
- Update the version number in ``configure.ac`` and re-run ``autoconf``. | ||
|
||
- Make sure the ``SOURCE_URI`` in ``Doc/tools/extensions/pyspecific.py`` | ||
points to ``master``. | ||
points to ``main``. | ||
|
||
- Update the version numbers for the Windows builds in PC/ and | ||
PCbuild/, which have references to python38. | ||
|
@@ -595,7 +595,7 @@ the main repo. | |
$ git mv -f PC/python38stub.def PC/python39stub.def | ||
$ git mv -f PC/python38gen.py PC/python39gen.py | ||
|
||
- Commit these changes to the master branch:: | ||
- Commit these changes to the main branch:: | ||
|
||
$ git status | ||
$ git add ... | ||
|
@@ -612,16 +612,16 @@ the main repo. | |
|
||
# For feature pre-releases prior to a **new branch** release, | ||
# i.e. a feature alpha release: | ||
$ git push --dry-run --tags [email protected]:python/cpython.git master | ||
$ git push --dry-run --tags [email protected]:python/cpython.git main | ||
# If it looks OK, take the plunge. There's no going back! | ||
$ git push --tags [email protected]:python/cpython.git master | ||
$ git push --tags [email protected]:python/cpython.git main | ||
|
||
# For a **new branch** release, i.e. first beta: | ||
$ git push --dry-run --tags [email protected]:python/cpython.git X.Y | ||
$ git push --dry-run --tags [email protected]:python/cpython.git master | ||
$ git push --dry-run --tags [email protected]:python/cpython.git main | ||
# If it looks OK, take the plunge. There's no going back! | ||
$ git push --tags [email protected]:python/cpython.git X.Y | ||
$ git push --tags [email protected]:python/cpython.git master | ||
$ git push --tags [email protected]:python/cpython.git main | ||
|
||
# For all other releases: | ||
$ git push --dry-run --tags [email protected]:python/cpython.git X.Y | ||
|
@@ -780,7 +780,7 @@ with RevSys.) | |
if this is a **new branch** release, remind everyone that the | ||
new release branch exists and that they need to start | ||
considering whether to backport to it when merging changes to | ||
master. | ||
main. | ||
|
||
- Update any release PEPs (e.g. 361) with the release dates. | ||
|
||
|
@@ -832,12 +832,12 @@ with RevSys.) | |
branch works (contact core-workflow team) | ||
https://github.com/python/core-workflow/issues | ||
|
||
- Review the most recent commit history for the master and new release | ||
- Review the most recent commit history for the main and new release | ||
branches to identify and backport any merges that might have been made | ||
to the master branch during the release engineering phase and that | ||
to the main branch during the release engineering phase and that | ||
should be in the release branch. | ||
|
||
- Verify that CI is working for new PRs for the master and new release | ||
- Verify that CI is working for new PRs for the main and new release | ||
branches and that the release branch is properly protected (no direct | ||
pushes, etc). | ||
|
||
|
@@ -986,7 +986,7 @@ This document has been placed in the public domain. | |
|
||
|
||
.. _docsbuild scripts: | ||
https://github.com/python/docsbuild-scripts/blob/master/build_docs.py | ||
https://github.com/python/docsbuild-scripts/blob/main/build_docs.py | ||
|
||
.. | ||
Local Variables: | ||
|