Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit97ad694

Browse files
authored
Remove mentions of EOL Python 3.8 (#1434)
1 parent356fea2 commit97ad694

File tree

3 files changed

+16
-18
lines changed

3 files changed

+16
-18
lines changed

‎developer-workflow/development-cycle.rst

Lines changed: 11 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -37,7 +37,7 @@ Branches
3737
--------
3838

3939
There is a branch for each *feature version*, whether released or not (for
40-
example, 3.7, 3.8).
40+
example, 3.12, 3.13).
4141

4242

4343
.. _indevbranch:
@@ -51,13 +51,11 @@ changes, performance improvements, bug fixes.
5151

5252
At some point during the life-cycle of a release, a
5353
new:ref:`maintenance branch<maintbranch>` is created to host all bug fixing
54-
activity for further micro versions in a feature version (3.8.1, 3.8.2, etc.).
54+
activity for further micro versions in a feature version (3.12.1, 3.12.2, and so
55+
on).
5556

56-
For versions 3.4 and before, this was conventionally done when the final
57-
release was cut (for example, 3.4.0 final).
58-
59-
Starting with the 3.5 release, we create the release maintenance branch
60-
(``3.5``) at the time we enter beta (3.5.0 beta 1). This allows
57+
We create the release maintenance branch
58+
(``3.14``) at the time we enter beta (3.14.0 beta 1). This allows
6159
feature development for the release 3.n+1 to occur within the main
6260
branch alongside the beta and release candidate stabilization periods
6361
for release 3.n.
@@ -79,7 +77,7 @@ releases; the terms are used interchangeably. These releases have a
7977
The only changes allowed to occur in a maintenance branch without debate are
8078
bug fixes, test improvements, and edits to the documentation.
8179
Also, a general rule for maintenance branches is that compatibility
82-
must not be broken at any point between sibling micro releases (3.5.1, 3.5.2,
80+
must not be broken at any point between sibling micro releases (3.12.1, 3.12.2,
8381
etc.). For both rules, only rare exceptions are accepted and **must** be
8482
discussed first.
8583

@@ -97,9 +95,9 @@ that maintenance branch.
9795
Sometime following the final release (3.x.0), the maintenance branch for
9896
the previous minor version will go into:ref:`security mode<secbranch>`,
9997
usually after at least one more bugfix release at the discretion of the
100-
release manager. For example, the 3.4 maintenance branch was put into
101-
:ref:`security mode<secbranch>` after the 3.4.4 bugfix release
102-
which followed the release of 3.5.1.
98+
release manager. For example, the 3.11 maintenance branch was put into
99+
:ref:`security mode<secbranch>` after the 3.11.9 bugfix release
100+
which followed the release of 3.12.2.
103101

104102
.. _secbranch:
105103

@@ -131,7 +129,7 @@ End-of-life branches
131129
The code base for a release cycle which has reached end-of-life status
132130
is frozen and no longer has a branch in the repo. The final state of
133131
the end-of-lifed branch is recorded as a tag with the same name as the
134-
former branch, for example, ``3.3`` or ``2.6``.
132+
former branch, for example, ``3.8`` or ``2.7``.
135133

136134
The:ref:`versions` page contains list of active and end-of-life branches.
137135

@@ -347,7 +345,7 @@ Current administrators
347345
| Pablo Galindo| Python 3.10 and 3.11 Release Manager,| pablogsal|
348346
|| Maintainer of buildbot.python.org||
349347
+-------------------+----------------------------------------------------------+-----------------+
350-
| Łukasz Langa| Python 3.8 and 3.9 Release Manager,| ambv|
348+
| Łukasz Langa| Python 3.9 Release Manager,| ambv|
351349
|| PSF CPython Developer in Residence 2021-present||
352350
+-------------------+----------------------------------------------------------+-----------------+
353351
| Brett Cannon|| brettcannon|

‎getting-started/setup-building.rst

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -116,8 +116,8 @@ in the ``cpython`` directory and two remotes that refer to your own GitHub fork
116116
117117
If you want a working copy of an already-released version of Python,
118118
that is, a version in:ref:`maintenance mode<maintbranch>`, you can checkout
119-
a release branch. For instance, to checkout a working copy of Python 3.8,
120-
do ``git switch 3.8``.
119+
a release branch. For instance, to checkout a working copy of Python 3.13,
120+
do ``git switch 3.13``.
121121

122122
You will need to re-compile CPython when you do such an update.
123123

@@ -730,9 +730,9 @@ some of CPython's modules (for example, ``zlib``).
730730
./configure --with-pydebug \
731731
--with-openssl="$(brew --prefix openssl@3)"
732732

733-
..tab::Python 3.8-3.10
733+
..tab::Python 3.9-3.10
734734

735-
For Python 3.8, 3.9, and 3.10::
735+
For Python 3.9 and 3.10::
736736

737737
$ CPPFLAGS="-I$(brew --prefix gdbm)/include -I$(brew --prefix xz)/include" \
738738
LDFLAGS="-L$(brew --prefix gdbm)/lib -L$(brew --prefix xz)/lib" \

‎internals/garbage-collector.rst

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -167,7 +167,7 @@ C APIs
167167

168168
Specific APIs are offered to allocate, deallocate, initialize, track, and untrack
169169
objects with GC support. These APIs can be found in the `Garbage Collector C API
170-
documentation <https://docs.python.org/3.8/c-api/gcsupport.html>`_.
170+
documentation <https://docs.python.org/3/c-api/gcsupport.html>`_.
171171

172172
Apart from this object structure, the type object for objects supporting garbage
173173
collection must include the ``Py_TPFLAGS_HAVE_GC`` in its ``tp_flags`` slot and

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp