Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork1.6k
Add python-releases.toml#4331
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
base:main
Are you sure you want to change the base?
Uh oh!
There was an error while loading.Please reload this page.
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
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 theversion 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 thehttps://endoflife.date/ API.
The alphahttps://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
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
# Conflicts:#peps/pep-0596.rst#peps/pep-0619.rst#peps/pep-0664.rst#peps/pep-0693.rst#peps/pep-0719.rst
| if sys.version_info >= (3, 11): | ||
| from release_engineering.generate_release_cycle import create_release_cycle | ||
| else: | ||
| # this function uses tomllib, which requires Python 3.11+ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
The comment would make more sense before line 31 or before line 30.This function here on lines 34-35 does not use tomllib!
But also, you could have a version-dependent dependency liketomli >= 1.1.0 ; python_version < "3.11" and a try/except import. But it’s up to you, I’m not well versed in release engineering to know when an older python would be used, and then whether a silent no-op is better than working or having a clear error 🙂
m-aciek left a comment• edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
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 withrelease topic and look for the metadata. What do you think?
| metadata: dict[str, 'VersionMetadata'] | ||
| releases: dict[str, list['ReleaseInfo']] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
| metadata:dict[str,'VersionMetadata'] | |
| releases:dict[str,list['ReleaseInfo']] | |
| metadata:dict[str,VersionMetadata] | |
| releases:dict[str,list[ReleaseInfo]] |
nit: withfrom future import annotations we can simplify here
| from __future__ import annotations | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
| from __future__ import annotations |
nit: this isn't needed
| return tuple(map(int, version.split('.'))) | ||
| def version_info(metadata: VersionMetadata, /) -> dict[str, str]: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
| defversion_info(metadata:VersionMetadata,/)->dict[str,str]: | |
| defversion_info(metadata:VersionMetadata,/)->dict[str,str|int]: |
PEP ID is anint
| # -- Python 1.6 -------------------------------------------------------------- | ||
| [metadata."1.6"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
nit: I wonder ifversion instead ofmetadata wouldn't make the config more obvious
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 |
Uh oh!
There was an error while loading.Please reload this page.
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 theversion 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