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

[AA-Turner]

I wonder, would it be possible to get all release matadata from the release PEPs, after enforcing the data structure using Sphinx/docutils features?

We could, but this would have a couple of considerations. Most importantly, we would need to change every previous release PEP, and this wouldn't easily permit going back before 1.6 if we wanted to record the metadata for 0.9-1.5.

I wouldn't be entirely opposed to this, though, as it preserves the nice quality that the PEPs remain the authoritative source for release information.

A

[AA-Turner]

Thanks for the review, I've responded to the comments (& fixed the formatting where it was wrong, thank you for pointing it out). I've also added the 1.6 alphas and corrected a few other dates/added more supporting links. I've updated the release manager for 1.6--2.1 to by Hylton & GvR, it seems that the current RM model didn't properly come into being until 2.1.

Lint failure is the ongoing pre-commit-uv problems.

A

[AA-Turner]

Python 3.9 failures are new and still related to the pre-commit-uv problems: https://github.com/tox-dev/pre-commit-uv/issues/70

A

[hugovk]

Python 3.9 failures are new and still related to the pre-commit-uv problems: tox-dev/pre-commit-uv#70

A

Now fixed and passes with a rebuild.

[ambv]

Just like with #4692, Imma be a tie breaker here and side with Hugo. I do think it's an API, even if it's read-only. But even if you disagree, this is such a minor detail, it's not worth blocking this otherwise great change to the release schedule PEP workflow.

[AA-Turner]

Just like with #4692, Imma be a tie breaker here and side with Hugo. I do think it's an API, even if it's read-only. But even if you disagree, this is such a minor detail, it's not worth blocking this otherwise great change to the release schedule PEP workflow.

Is this the right issue/PR reference? I continue to believe that /api is the wrong choice here with needless nesting, but nevertheless, thank you for merging.

A

[merwok]

I think #4231 was meant.