PEP 101: Updates (#4136)

Author: hugovk

peps/pep-0101.rst

@@ -33,10 +33,13 @@ Here's a hopefully-complete list.
 
 * A GPG key.
 
-  Python releases are digitally signed with GPG; you'll need a key,
-  which hopefully will be on the "web of trust" with at least one of
+  Python releases before 3.14 are digitally signed with GPG; for these you'll
+  need a key, which hopefully will be on the "web of trust" with at least one of
   the other release managers.
 
+  .. note:: GPG instructions in this PEP can be ignored for Python 3.14 and
+            later. See :pep:`761` for details.
+
 * A bunch of software:
 
   * A checkout of the `python/release-tools`_ repo.
@@ -263,20 +266,6 @@ to perform some manual editing steps.
 - Make sure all changes have been committed.  (``release.py --bump``
   doesn't check in its changes for you.)
 
-- Check the years on the copyright notice.  If the last release
-  was some time last year, add the current year to the copyright
-  notice in several places:
-
-  - ``README``
-  - ``LICENSE`` (make sure to change on ``main`` and the branch)
-  - ``Python/getcopyright.c``
-  - ``Doc/copyright.rst``
-  - ``Doc/license.rst``
-  - ``PC/python_ver_rc.h`` sets up the DLL version resource for Windows
-    (displayed when you right-click on the DLL and select
-    Properties).  This isn't a C include file, it's a Windows
-    "resource file" include file.
-
 - For a **final** major release, edit the first paragraph of
   ``Doc/whatsnew/3.X.rst`` to include the actual release date; e.g. "Python
   2.5 was released on August 1, 2003."  There's no need to edit this for
@@ -610,7 +599,7 @@ the main repo.
   release branch (3.X-1) and use them as a template.
   https://github.com/python/cpython/settings/branches
 
-  Also, add a ``needs backport to 3.X`` label to the GitHub repo.
+  Also, add ``3.x`` and ``needs backport to 3.X`` labels to the GitHub repo.
   https://github.com/python/cpython/labels
 
 - You can now re-enable enforcement of branch settings against administrators
@@ -637,7 +626,7 @@ permissions.
   Python release "page", editing as you go.
 
   You can use `Markdown <https://daringfireball.net/projects/markdown/syntax>`_ or
-  `reStructured Text <http://docutils.sourceforge.net/docs/user/rst/quickref.html>`_
+  `reStructured Text <https://docutils.sourceforge.io/docs/user/rst/quickref.html>`_
   to describe your release.  The former is less verbose, while the latter has nifty
   integration for things like referencing PEPs.
 
@@ -742,28 +731,20 @@ permissions.
 
   * python-list@python.org
   * python-announce@python.org
-  * python-dev@python.org
 
 - Also post the announcement to the
-  `Python Insider blog <http://blog.python.org>`_.
+  `Python Insider blog <https://blog.python.org>`_.
   To add a new entry, go to
-  `your Blogger home page, here <https://www.blogger.com/home>`_.
+  `your Blogger home page <https://www.blogger.com/home>`_.
 
-- Update any release PEPs (e.g. 719) with the release dates.
+- Update `release PEPs <https://peps.python.org/topic/release/>`__
+  (e.g. 719) with the release dates.
 
 - Update the labels on https://github.com/python/cpython/issues:
 
   - Flip all the `deferred-blocker`_ issues back to `release-blocker`_
     for the next release.
 
-  - Add version ``3.X+1`` as when version ``3.X`` enters alpha.
-
-  - Change non-doc feature requests to version ``3.X+1`` when version ``3.X``
-    enters beta.
-
-  - Update issues from versions that your release makes
-    unsupported to the next supported version.
-
   - Review open issues, as this might find lurking showstopper bugs,
     besides reminding people to fix the easy ones they forgot about.
 
@@ -788,7 +769,7 @@ permissions.
     or Zach Ware).
 
   - Ensure the various GitHub bots are updated, as needed, for the
-    new branch, in particular, make sure backporting to the new
+    new branch. In particular, make sure backporting to the new
     branch works (contact the `core-workflow team
     <https://github.com/python/core-workflow/issues>`__).
 
@@ -801,7 +782,7 @@ permissions.
     branches and that the release branch is properly protected (no direct
     pushes, etc).
 
-  - Verify that the `on-line docs <https://docs.python.org/>`__ are building
+  - Verify that the `online docs <https://docs.python.org/>`__ are building
     properly (this may take up to 24 hours for a complete build on the website).
 
 
@@ -869,12 +850,16 @@ else does them.  Some of those tasks include:
 
 - Retire the release from the `issue tracker`_. Tasks include:
 
+  * update issues from this version to the next supported version
+
   * remove version label from list of versions
 
   * remove the ``needs backport to`` label for the retired version
 
   * review and dispose of open issues marked for this branch
 
+- Run a final build of the online docs to add the end-of-life banner
+
 - Announce the branch retirement in the usual places:
 
   * `discuss.python.org`_