Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork1.6k
Infra: Move release dates from RSTs to JSON#4314
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.
Interesting idea! Comments in threads for easier replying:
A
| release_list = "\n".join(f"<li>{release}" for release in releases) | ||
| return f'<ul class="simple">{release_list}</ul>' |
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.
It's better to do this in the AST rather than the writer (e.g HTML)
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.
Is the idea for this file to replace e.g. the devguide one, or be used to build the version switcher on d.p.o? If so, I think having the 'official' location be the PEPs repo feels a bit hidden. The devguide feels 'best' as it is non-versioned, but equally we get complaints that that is non-obvious.
If we do want a single-data-file-of-truth, I would probably suggest putting all of the devguide fields into this one, as otherwise it gets more complex/annoying with multiple slightly different files describing roughly the same thing.
On a practicalities level, I'd suggest using TOML, which has both support for dates, comments, trailing commas, etc and slightly nicer formatting for human consumption. E.g.:
[[3.14]]stage ="development begins"date =2024-05-08actual =true[[3.14]]# ...[[3.14]]stage ="beta 1"date =2025-05-06actual =false
A
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.
Is the idea for this file to replace e.g. the devguide one, or be used to build the version switcher on d.p.o?
Yes, I'm primarily thinking of replacing the devguide one.
If so, I think having the 'official' location be the PEPs repo feels a bit hidden. The devguide feels 'best' as it is non-versioned, but equally we get complaints that that is non-obvious.
My thinking of it being here is because this is where the equivalent release PEPs are. When the 3.15 PEP is added, it can be done right here in both RST and data file. This is the PEPs spec repo, this is where you come for the release dates now, it feels right the definitive release dates are retained in the same place.
TOML, possibly, although that would make it harder to use for example in JavaScript.
Uh oh!
There was an error while loading.Please reload this page.
First step to moving release dates from the reStructedText files into a JSON file.
This will mean we have the release data in a single canonical location for re-use elsewhere.
For example:
I suggest we do:
In this first PR, I've only moved the dates out of 3.14.
No end-of-bugfix or end-of-life or listed yet, let's check the JSON structure looks right, and if this is the right way to do it in Sphinx.
We'll also need a way to add notes, such as the hotfixes and recalls in3.9 and3.8 -- thoughts on that?
📚 Documentation preview 📚:https://pep-previews--4314.org.readthedocs.build/pep-0745/#release-schedule