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

PEP 101: Resolve uses of the default role (#3368)

This commit is contained in:
Adam Turner 2023-09-01 20:18:36 +01:00 committed by GitHub
parent 34022280b9
commit 10f48f67d8
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 10 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
pep-0101.txt
View File

@ -212,7 +212,7 @@ to perform some manual editing steps.
within it (called the "release clone" from now on). You can use the same within it (called the "release clone" from now on). You can use the same
GitHub fork you use for cpython development. Using the standard setup GitHub fork you use for cpython development. Using the standard setup
recommended in the Python Developer's Guide, your fork would be referred recommended in the Python Developer's Guide, your fork would be referred
to as `origin` and the standard cpython repo as `upstream`. You will to as ``origin`` and the standard cpython repo as ``upstream``. You will
use the branch on your fork to do the release engineering work, including use the branch on your fork to do the release engineering work, including
tagging the release, and you will use it to share with the other experts tagging the release, and you will use it to share with the other experts
for making the binaries. for making the binaries.
@ -302,7 +302,7 @@ to perform some manual editing steps.
$ .../release-tools/release.py --tag X.Y.ZaN $ .../release-tools/release.py --tag X.Y.ZaN
This executes a `git tag` command with the `-s` option so that the This executes a ``git tag`` command with the ``-s`` option so that the
release tag in the repo is signed with your gpg key. When prompted release tag in the repo is signed with your gpg key. When prompted
choose the private key you use for signing release tarballs etc. choose the private key you use for signing release tarballs etc.
@ -538,7 +538,7 @@ the main repo.
do some post-merge cleanup. Check the top-level ``README.rst`` do some post-merge cleanup. Check the top-level ``README.rst``
and ``include/patchlevel.h`` files to ensure they now reflect and ``include/patchlevel.h`` files to ensure they now reflect
the desired post-release values for on-going development. the desired post-release values for on-going development.
The patchlevel should be the release tag with a `+`. The patchlevel should be the release tag with a ``+``.
Also, if you cherry-picked changes from the standard release Also, if you cherry-picked changes from the standard release
branch into the release engineering branch for this release, branch into the release engineering branch for this release,
you will now need to manual remove each blurb entry from you will now need to manual remove each blurb entry from
@ -546,8 +546,8 @@ the main repo.
into the release you are working on since that blurb entry into the release you are working on since that blurb entry
is now captured in the merged x.y.z.rst file for the new is now captured in the merged x.y.z.rst file for the new
release. Otherwise, the blurb entry will appear twice in release. Otherwise, the blurb entry will appear twice in
the `changelog.html` file, once under `Python next` and again the ``changelog.html`` file, once under ``Python next`` and again
under `x.y.z`. under ``x.y.z``.
- Review and commit these changes:: - Review and commit these changes::
@ -712,19 +712,19 @@ with RevSys.)
- If this is a **final** release: - If this is a **final** release:
- Add the new version to the *Python Documentation by Version* - Add the new version to the *Python Documentation by Version*
page `https://www.python.org/doc/versions/` and page ``https://www.python.org/doc/versions/`` and
remove the current version from any 'in development' section. remove the current version from any 'in development' section.
- For X.Y.Z, edit all the previous X.Y releases' page(s) to - For X.Y.Z, edit all the previous X.Y releases' page(s) to
point to the new release. This includes the content field of the point to the new release. This includes the content field of the
`Downloads -> Releases` entry for the release:: ``Downloads -> Releases`` entry for the release::
Note: Python x.y.m has been superseded by Note: Python x.y.m has been superseded by
`Python x.y.n </downloads/release/python-xyn/>`_. `Python x.y.n </downloads/release/python-xyn/>`_.
And, for those releases having separate release page entries And, for those releases having separate release page entries
(phasing these out?), update those pages as well, (phasing these out?), update those pages as well,
e.g. `download/releases/x.y.z`:: e.g. ``download/releases/x.y.z``::
Note: Python x.y.m has been superseded by Note: Python x.y.m has been superseded by
`Python x.y.n </download/releases/x.y.n/>`_. `Python x.y.n </download/releases/x.y.n/>`_.
@ -908,8 +908,8 @@ else does them. Some of those tasks include:
- Remove the release from the list of "Active Python Releases" on the Downloads - Remove the release from the list of "Active Python Releases" on the Downloads
page. To do this, log in to the admin page for python.org, navigate to Boxes, page. To do this, log in to the admin page for python.org, navigate to Boxes,
and edit the `downloads-active-releases` entry. Simply strip out the relevant and edit the ``downloads-active-releases`` entry. Simply strip out the relevant
paragraph of HTML for your release. (You'll probably have to do the `curl -X PURGE` paragraph of HTML for your release. (You'll probably have to do the ``curl -X PURGE``
trick to purge the cache if you want to confirm you made the change correctly.) trick to purge the cache if you want to confirm you made the change correctly.)
- Add retired notice to each release page on python.org for the retired branch. - Add retired notice to each release page on python.org for the retired branch.