@@ -37,7 +37,7 @@ Branches
 --------
 
 There is a branch for each *feature version*, whether released or not (for
-example, 3.7, 3.8).
+example, 3.12, 3.13).
 
 
 .. _indevbranch:
@@ -51,13 +51,11 @@ changes, performance improvements, bug fixes.
 
 At some point during the life-cycle of a release, a
 new :ref:`maintenance branch <maintbranch>` is created to host all bug fixing
-activity for further micro versions in a feature version (3.8.1, 3.8.2, etc.).
+activity for further micro versions in a feature version (3.12.1, 3.12.2, and so
+on).
 
-For versions 3.4 and before, this was conventionally done when the final
-release was cut (for example, 3.4.0 final).
-
-Starting with the 3.5 release, we create the release maintenance branch
-(``3.5``) at the time we enter beta (3.5.0 beta 1).  This allows
+We create the release maintenance branch
+(``3.14``) at the time we enter beta (3.14.0 beta 1).  This allows
 feature development for the release 3.n+1 to occur within the main
 branch alongside the beta and release candidate stabilization periods
 for release 3.n.
@@ -79,7 +77,7 @@ releases; the terms are used interchangeably. These releases have a
 The only changes allowed to occur in a maintenance branch without debate are
 bug fixes, test improvements, and edits to the documentation.
 Also, a general rule for maintenance branches is that compatibility
-must not be broken at any point between sibling micro releases (3.5.1, 3.5.2,
+must not be broken at any point between sibling micro releases (3.12.1, 3.12.2,
 etc.).  For both rules, only rare exceptions are accepted and **must** be
 discussed first.
 
@@ -97,9 +95,9 @@ that maintenance branch.
 Sometime following the final release (3.x.0), the maintenance branch for
 the previous minor version will go into :ref:`security mode <secbranch>`,
 usually after at least one more bugfix release at the discretion of the
-release manager.  For example, the 3.4 maintenance branch was put into
-:ref:`security mode <secbranch>` after the 3.4.4 bugfix release
-which followed the release of 3.5.1.
+release manager.  For example, the 3.11 maintenance branch was put into
+:ref:`security mode <secbranch>` after the 3.11.9 bugfix release
+which followed the release of 3.12.2.
 
 .. _secbranch:
 
@@ -131,7 +129,7 @@ End-of-life branches
 The code base for a release cycle which has reached end-of-life status
 is frozen and no longer has a branch in the repo.  The final state of
 the end-of-lifed branch is recorded as a tag with the same name as the
-former branch, for example, ``3.3`` or ``2.6``.
+former branch, for example, ``3.8`` or ``2.7``.
 
 The :ref:`versions` page contains list of active and end-of-life branches.
 
@@ -347,7 +345,7 @@ Current administrators
 | Pablo Galindo     | Python 3.10 and 3.11 Release Manager,                    | pablogsal       |
 |                   | Maintainer of buildbot.python.org                        |                 |
 +-------------------+----------------------------------------------------------+-----------------+
-| Łukasz Langa      | Python 3.8 and 3.9 Release Manager,                      | ambv            |
+| Łukasz Langa      | Python 3.9 Release Manager,                              | ambv            |
 |                   | PSF CPython Developer in Residence 2021-present          |                 |
 +-------------------+----------------------------------------------------------+-----------------+
 | Brett Cannon      |                                                          | brettcannon     |
 
@@ -116,8 +116,8 @@ in the ``cpython`` directory and two remotes that refer to your own GitHub fork
 
 If you want a working copy of an already-released version of Python,
 that is, a version in :ref:`maintenance mode <maintbranch>`, you can checkout
-a release branch. For instance, to checkout a working copy of Python 3.8,
-do ``git switch 3.8``.
+a release branch. For instance, to checkout a working copy of Python 3.13,
+do ``git switch 3.13``.
 
 You will need to re-compile CPython when you do such an update.
 
@@ -730,9 +730,9 @@ some of CPython's modules (for example, ``zlib``).
                ./configure --with-pydebug \
                            --with-openssl="$(brew --prefix openssl@3)"
 
-      .. tab:: Python 3.8-3.10
+      .. tab:: Python 3.9-3.10
 
-         For Python 3.8, 3.9, and 3.10::
+         For Python 3.9 and 3.10::
 
             $ CPPFLAGS="-I$(brew --prefix gdbm)/include -I$(brew --prefix xz)/include" \
                LDFLAGS="-L$(brew --prefix gdbm)/lib -L$(brew --prefix xz)/lib" \
 
@@ -167,7 +167,7 @@ C APIs
 
 Specific APIs are offered to allocate, deallocate, initialize, track, and untrack
 objects with GC support. These APIs can be found in the `Garbage Collector C API
-documentation <https://docs.python.org/3.8/c-api/gcsupport.html>`_.
+documentation <https://docs.python.org/3/c-api/gcsupport.html>`_.
 
 Apart from this object structure, the type object for objects supporting garbage
 collection must include the ``Py_TPFLAGS_HAVE_GC`` in its ``tp_flags`` slot and