| Oct | NOV | Dec |
| 25 | ||
| 2019 | 2020 | 2021 |
COLLECTED BY
Collection: Common Crawl
●Python »
Python Developer's Guide »
major.minor.micro nomenclature
for production-ready releases. So for Python 3.1.2 final, that is a major
version of 3, a minor version of 1, and a micro version of 2.
●new major versions are exceptional; they only come when strongly
incompatible changes are deemed necessary, and are planned very long
in advance;
●new minor versions are feature releases; they get released annually,
from the current in-development branch;
●new micro versions are bugfix releases; they get released roughly
every 2 months; they are prepared in maintenance
branches.
We also publish non-final versions which get an additional qualifier:
Alpha, Beta, release candidate. These versions
are aimed at testing by advanced users, not production use.
Each release of Python is tagged in the source repo with a tag of the form
vX.Y.ZTN, where Xis the major version, Yis the
minor version, Zis the micro version, Tis the release level
(a for alpha releases, bfor beta, rcrelease candidate,
and null for final releases), and Nis the release serial number.
Some examples of release tags: v3.7.0a1, v3.6.3, v2.7.14rc1.
master branch is the branch for the next feature release; it is
under active development for all kinds of changes: new features, semantic
changes, performance improvements, bug fixes.
At some point during the life-cycle of a release, a
new maintenance branch is created to host all bug fixing
activity for further micro versions in a feature version (3.8.1, 3.8.2, etc.).
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
(e.g. 3.5) at the time we enter beta (3.5.0 beta 1). This allows
feature development for the release 3.n+1 to occur within the master
branch alongside the beta and release candidate stabilization periods
for release 3.n.
3.3or2.6.
For reference, here are the Python versions that most recently reached their end-of-life:
| Branch | Schedule | First release | End-of-life | Release manager |
|---|---|---|---|---|
| 3.5 | PEP 478 | 2015-09-13 | 2020-09-30 | Larry Hastings |
| 3.4 | PEP 429 | 2014-03-16 | 2019-03-18 | Larry Hastings |
| 3.3 | PEP 398 | 2012-09-29 | 2017-09-29 | Georg Brandl, Ned Deily (3.3.7+) |
| 3.2 | PEP 392 | 2011-02-20 | 2016-02-20 | Georg Brandl |
| 3.1 | PEP 375 | 2009-06-27 | 2012-04-09 | Benjamin Peterson |
| 3.0 | PEP 361 | 2008-12-03 | 2009-06-27 | Barry Warsaw |
| 2.7 | PEP 373 | 2010-07-03 | 2020-01-01 | Benjamin Peterson |
| 2.6 | PEP 361 | 2008-10-01 | 2013-10-29 | Barry Warsaw |
| Name | Role | GitHub Username |
|---|---|---|
| Benjamin Peterson | Infrastructure Staff | benjaminp |
| Noah Kantrowitz | Infrastructure Staff | coderanger |
| Donald Stufft | Infrastructure Staff | dstufft |
| Ewa Jodlowska | PSF Executive Director | ejodlowska |
| Ernest W. Durbin III | PSF Director of Infrastructure | ewdurbin |
| Van Lindberg | PSF General Counsel | VanL |
| Name | Role | GitHub Username |
|---|---|---|
| Pablo Galindo | Python 3.10 and 3.11 Release Manager, Maintainer of buildbot.python.org | pablogsal |
| Łukasz Langa | Python 3.8 and 3.9 Release Manager | ambv |
| Ned Deily | Python 3.6 and 3.7 Release Manager | ned-deily |
| Lary Hastings | Python 3.5 Release Manager | larryhastings |
| Berker Peksag | Maintainer of bpo-linkify and cpython-emailer-webhook | berkerpeksag |
| Brett Cannon | Maintainer of bedevere and the-knights-who-say-ni | brettcannon |
| Ezio Melotti | Maintainer of bugs.python.org GitHub webhook integration | ezio-melotti |
| Mariatta Wijaya | Maintainer of blurb_it and miss-islington | Mariatta |
●Python »
Python Developer's Guide »