iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Update references to master to point to main (#1948)

This commit is contained in:
Pablo Galindo 2021-05-08 04:24:21 +01:00 committed by GitHub
parent aae66b2c4b
commit fae0ce2014
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 22 additions and 22 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

44
pep-0101.txt
View File

@ -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 Some of these release types actually involve more than
one release branch. In particular, a **new branch** is that point in the 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 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 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 next feature release, a **new branch** release is made which creates a
new separate branch for stabilization and later maintenance of the 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). 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 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 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. if there are differences, commit them.
- Make sure the ``SOURCE_URI`` in ``Doc/tools/extensions/pyspecific.py`` - Make sure the ``SOURCE_URI`` in ``Doc/tools/extensions/pyspecific.py``
points to the right branch in the git repository (``master`` or ``X.Y``). 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 *master* 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``). to the new release branch you are about to create (``X.Y``).
- Bump version numbers via the release script:: - Bump version numbers via the release script::
@ -502,8 +502,8 @@ the main repo.
# Checkout the correct branch: # Checkout the correct branch:
# 1. For feature pre-releases up to and including a # 1. For feature pre-releases up to and including a
# **new branch** release, i.e. alphas and first beta # **new branch** release, i.e. alphas and first beta
# do a checkout of the master branch # do a checkout of the main branch
$ git checkout master $ git checkout main
# 2. Else, for all other releases, checkout the # 2. Else, for all other releases, checkout the
# appropriate release branch. # appropriate release branch.
@ -522,7 +522,7 @@ the main repo.
Do any steps needed to setup the new release branch, including: 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. the new branch, in particular, GitHub repo URLs.
- For *all* releases, do the guided post-release steps with the - For *all* releases, do the guided post-release steps with the
@ -550,13 +550,13 @@ the main repo.
$ git commit -m 'Post release updates' $ git commit -m 'Post release updates'
- If this is a **new branch** release (e.g. the first beta), - If this is a **new branch** release (e.g. the first beta),
update the master branch to start development for the update the main branch to start development for the
following feature release. When finished, the ``master`` following feature release. When finished, the ``main``
branch will now build Python ``X.Y+1``. 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 $ .../release-tools/release.py --bump 3.9.0a0
- Edit all version references in README.rst - 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``. - Update the version number in ``configure.ac`` and re-run ``autoconf``.
- Make sure the ``SOURCE_URI`` in ``Doc/tools/extensions/pyspecific.py`` - 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 - Update the version numbers for the Windows builds in PC/ and
PCbuild/, which have references to python38. 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/python38stub.def PC/python39stub.def
$ git mv -f PC/python38gen.py PC/python39gen.py $ 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 status
$ git add ... $ git add ...
@ -612,16 +612,16 @@ the main repo.
# For feature pre-releases prior to a **new branch** release, # For feature pre-releases prior to a **new branch** release,
# i.e. a feature alpha 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! # 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: # 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 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! # 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 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: # For all other releases:
$ git push --dry-run --tags git@github.com:python/cpython.git X.Y $ 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 if this is a **new branch** release, remind everyone that the
new release branch exists and that they need to start new release branch exists and that they need to start
considering whether to backport to it when merging changes to considering whether to backport to it when merging changes to
master. main.
- Update any release PEPs (e.g. 361) with the release dates. - Update any release PEPs (e.g. 361) with the release dates.
@ -832,12 +832,12 @@ with RevSys.)
branch works (contact core-workflow team) branch works (contact core-workflow team)
https://github.com/python/core-workflow/issues 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 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. 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 branches and that the release branch is properly protected (no direct
pushes, etc). pushes, etc).
@ -986,7 +986,7 @@ This document has been placed in the public domain.
.. _docsbuild scripts: .. _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: Local Variables: