Update references to master to point to main (#1948)
This commit is contained in:
Pablo Galindo
GitHub
parent
aae66b2c4b
commit
fae0ce2014
44
pep-0101.txt
44
pep-0101.txt
|
|
@ -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 git@github.com:python/cpython.git master
|
||||
$ git push --dry-run --tags git@github.com:python/cpython.git main
|
||||
# If it looks OK, take the plunge. There's no going back!
|
||||
$ git push --tags git@github.com:python/cpython.git master
|
||||
$ git push --tags git@github.com:python/cpython.git main
|
||||
|
||||
# For a **new branch** release, i.e. first beta:
|
||||
$ git push --dry-run --tags git@github.com:python/cpython.git X.Y
|
||||
$ git push --dry-run --tags git@github.com:python/cpython.git master
|
||||
$ git push --dry-run --tags git@github.com:python/cpython.git main
|
||||
# If it looks OK, take the plunge. There's no going back!
|
||||
$ git push --tags git@github.com:python/cpython.git X.Y
|
||||
$ git push --tags git@github.com:python/cpython.git master
|
||||
$ git push --tags git@github.com:python/cpython.git main
|
||||
|
||||
# For all other releases:
|
||||
$ git push --dry-run --tags git@github.com: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:
|
||||
|
|
|
|||
Loading…
Reference in New Issue