Conversation
f5aadff to
954a97a
Compare
| "url": "https://github.com/pyodide/pyodide/releases/download/314.0.0a1/xbuildenv-314.0.0a1.tar.bz2", | ||
| "sha256": null, | ||
| "variant": null, | ||
| "build": "314.0.0a1" |
There was a problem hiding this comment.
We're changing our versioning, if that is what you are referring to.
There was a problem hiding this comment.
Well, the build is 314.0.0a1 but the CPython version is 3.14.2?
I'm also not sure what to do with pre-release build tags, that's not a concept we support today.
Can you explain the new versioning scheme perhaps?
There was a problem hiding this comment.
I think the prerelease pyodide versions should be ignored by uv, I don't see any reason that uv should allow installing them.
The idea with the new versioning scheme was that we would put Python majorminor as the major version and then we increment the minor version when we do main branch releases and the patch version when we do backports. We haven't made a stable release following this convention yet so if you think that it is a really bad idea we could still change it if there is a compelling enough reason.
`PyodideFinder` was reading every release from the GitHub API, including prereleases. Pyodide's `pyodide-cross-build-environments.json` only exposes a `python_version` string with no prerelease marker, so an alpha release like `314.0.0a1` was emitted as if it targeted stable CPython 3.14.2 — the generated entry's `prerelease` field was `""` while its `build` field was `314.0.0a1`, which is the discrepancy surfaced on astral-sh#18958. Filter releases on `release["prerelease"]` so Pyodide alphas/betas are ignored, matching the implicit stable-only policy of the other finders. https://claude.ai/code/session_014joASNw6BxUAgDVxsnPZFj
5c2456e to
832a7cb
Compare
832a7cb to
697b008
Compare
Automated update for Python releases.