Replace local release-cycle.json with PEPs repo version
We now generate and publish release-cycle.json from the PEPs repo (https://github.com/python/peps/pull/4331) so can use that directly and don't need to duplicate this data.
📚 Documentation preview 📚: https://cpython-devguide--1685.org.readthedocs.build/
It might be better ad interim to have the devguide just copy & republish (or redirect to?) the PEPs release-cycle.json?
A
Yes, that's a good idea.
Yeah, they also need updating to point to peps.python.org/api/release-cycle.json
Let's update/notify the ones we know about before merging.
I've opened a bunch of PRs to update most of the public GitHub repos using this file.
It might be better ad interim to have the devguide just copy & republish (or redirect to?) the PEPs
release-cycle.json?A
Hm, seeing as this was never published under https://devguide.python.org/ and people were just fetching the file directly from the repo using something like https://raw.githubusercontent.com/python/devguide/main/include/release-cycle.json, we can't have a redirect, because there's nothing to redirect.
It's just a file in the repo. So we'd need to add some automation that downloads the new file, and then commits it here.
Or we do update it manually from time to time.
I'm not so keen on either of those.
Because we never "officially published" this file, it was something used internally in this repo, I suggest we wait a little while for the important PRs above to be merged, then go ahead with this one.
And rather than completely delete the file here (which would give 404) we could put an error message in the file saying to use the new file instead. This could either be plain text, or some basic JSON such as {"notice": "This file has moved to https://peps.python.org/api/release-cycle.json"}?
Ah, yes. Perhaps let's wait at least a fortnight, but no later than the end of the year -- the only downside will be stale data in the devguide (I don't propose we'd make any further updates here).
I'd prefer to delete entirely, but adding some sort of note in the file could make sense. We could also add something to README / use an announcement issue. A 404 isn't terrible as it is an early and hard failure, whereas changing the JSON structure could have confusing errors. Luckily though the impact doesn't seem massive, there's only a dozen or so third-party uses on GitHub.
A
It's been a fortnight and most of the update PRs, and all the important ones, have been merged.
Ready for merge!