Add python-releases.toml

[AA-Turner]

Inspired by #4314, this PR adds a transcription of every Python release since version 1.6 into a single TOML document, python-releases.toml. This is intended to serve as a single, centralised, machine-readable record of Python's release history (and future).

From this, we automatically generate a release-cycle.json file as part of the build process, to be published on peps.python.org. This replaces the version in the devguide.

The TOML document is used to (re-)generate the release schedules contained in release PEPs, initially starting with those for Python 3.8 to 3.14. The authoritative record and history remains the release PEP.

Some releases may need optional annotations or notes, which I have filled in for Python 3.8 and 3.9, but not yet back-filled.

Open questions:

• Any better ideas for a filename than python-releases.toml?
• Should the file live at the top level, or in the a subdirectory (as at present)?
• Any better ideas for the metadata field names? I'm not a great fan of start-of-development and end-of-bugfix, as all the others can be said aloud as "The {first release / feature freeze / end of life} is/was on {date}".
• Are the release managers for Pythons 1.6-2.2 correct?

A

---

📚 Documentation preview 📚: https://pep-previews--4331.org.readthedocs.build/
📚 Documentation preview 📚: https://pep-previews--4331.org.readthedocs.build/release-cycle.json

[hugovk]

Partial review:

From this, we automatically generate a release-cycle.json file as part of the build process, to be published on peps.python.org. This replaces the version in the devguide.

Can we make all the data in the TOML also available in the JSON?

JSON is more universally supported, and we should make this data as widely usable as possible.

We don't necessarily need the JSON here to be an exact copy of the old devguide one; as long as the devguide can read the data it needs from this JSON to construct the diagram and tables.

Open questions:

• Any better ideas for a filename than python-releases.toml?

Fine by me.

• Any better ideas for the metadata field names? I'm not a great fan of start-of-development and end-of-bugfix, as all the others can be said aloud as "The {first release / feature freeze / end of life} is/was on {date}".

We could use the same names as the https://endoflife.date/ API.

The alpha https://endoflife.date/api/python.json currently uses:

• releaseDate - initial release
• support - end of bugfix
• eol - end of security support / life

Or the WIP v1 API (endoflife-date/endoflife.date#2080), https://deploy-preview-2080--endoflife-date.netlify.app/api/v1/products/python uses:

• date - initial release
• eoasFrom - end of bugfix (end of active support)
• eolFrom - end of security support / life