Add python-releases.toml #4331
Add python-releases.toml #4331
Conversation
hugovk
left a comment
hugovk
left a comment
There was a problem hiding this comment.
Partial review:
From this, we automatically generate a
release-cycle.jsonfile as part of the build process, to be published onpeps.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-developmentandend-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 releasesupport- end of bugfixeol- 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 releaseeoasFrom- end of bugfix (end of active support)eolFrom- end of security support / life
pep_sphinx_extensions/pep_zero_generator/pep_index_generator.py
Outdated
Show resolved
Hide resolved
# Conflicts: # peps/pep-0596.rst # peps/pep-0619.rst # peps/pep-0664.rst # peps/pep-0693.rst # peps/pep-0719.rst
pep_sphinx_extensions/pep_zero_generator/pep_index_generator.py
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
I've left some minor comments.
The centralised file is 3400 lines long. I wonder, would it be possible to get all release metadata from the release PEPs, after enforcing the data structure using Sphinx/docutils features? This way the source of truth would be PEPs with machine-extractable data, and the data would be much easier to maintain/add. Then JSON/TOML would be generated in CI or locally automatically from the PEPs. Automatic script would go through all informational PEPs with release topic and look for the metadata. What do you think?
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 |
# Conflicts: # peps/pep-0596.rst # peps/pep-0619.rst # peps/pep-0664.rst # peps/pep-0719.rst
hugovk
left a comment
hugovk
left a comment
There was a problem hiding this comment.
Summary of discussion with Adam at EuroPython sprints:
I'd like us to provide the full data as JSON, so it's more widely available, for example, when using JavaScript.
I don't mind the source data being in TOML or JSON. It is extra work to convert from TOML to JSON, but that shouldn't be too hard, and TOML is a bit nicer to edit by hand.
I also don't mind if we provide the same smaller release-cycle.json file for the devguide to consume, or update the devguide to read the full one. Adam has preference for the small file.
pep_sphinx_extensions/pep_zero_generator/pep_index_generator.py
Outdated
Show resolved
Hide resolved
Now fixed and passes with a rebuild. |
|
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. |
| commands = ( | ||
| CMD_FULL_JSON := 'full-json', | ||
| CMD_UPDATE_PEPS := 'update-peps', | ||
| CMD_RELEASE_CYCLE := 'release-cycle', |
There was a problem hiding this comment.
walrus strikes again! nice idiom when not using an enum.
Is this the right issue/PR reference? I continue to believe that A |
This file is now generated and published from the PEPs repo (python/peps#4331) and will be removed from the devguide soon (python/devguide#1685).
|
I think #4231 was meant. |
This file is now generated and published from the PEPs repo (python/peps#4331) and will be removed from the devguide soon (python/devguide#1685).
5 participants
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.jsonfile as part of the build process, to be published onpeps.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:
python-releases.toml?start-of-developmentandend-of-bugfix, as all the others can be said aloud as "The {first release / feature freeze / end of life} is/was on {date}".A
📚 Documentation preview 📚: https://pep-previews--4331.org.readthedocs.build/
📚 Documentation preview 📚: https://pep-previews--4331.org.readthedocs.build/release-cycle.json