| Oct | NOV | Dec |
| 11 | ||
| 2019 | 2020 | 2021 |
COLLECTED BY
Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
History is littered with hundreds of conflicts over the future of a community, group, location or business that were "resolved" when one of the parties stepped ahead and destroyed what was there. With the original point of contention destroyed, the debates would fall to the wayside. Archive Team believes that by duplicated condemned data, the conversation and debate can continue, as well as the richness and insight gained by keeping the materials. Our projects have ranged in size from a single volunteer downloading the data to a small-but-critical site, to over 100 volunteers stepping forward to acquire terabytes of user-created data to save for future generations.
The main site for Archive Team is at archiveteam.org and contains up to the date information on various projects, manifestos, plans and walkthroughs.
This collection contains the output of many Archive Team projects, both ongoing and completed. Thanks to the generous providing of disk space by the Internet Archive, multi-terabyte datasets can be made available, as well as in use by the Wayback Machine, providing a path back to lost websites and work.
Our collection has grown to the point of having sub-collections for the type of data we acquire. If you are seeking to browse the contents of these collections, the Wayback Machine is the best first stop. Otherwise, you are free to dig into the stacks to see what you may find.
The Archive Team Panic Downloads are full pulldowns of currently extant websites, meant to serve as emergency backups for needed sites that are in danger of closing, or which will be missed dearly if suddenly lost due to hard drive crashes or server failures.
Collection: Archive Team: URLs
●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 »