Add manifest.json as the runtime source of truth#15
Merged
Conversation
manifest.json now drives the CI build matrix (the setup job reads [.pythons[].full_version] from it) and is published as a release asset with the release date injected, so serious_python and flet consume a single consistent version set (CPython + pyodide + dart_bridge) keyed by release date instead of hand-mirroring versions.
Update .github/workflows/build-python.yml to use actions/checkout@v6 instead of v4 in both jobs. This brings the workflow up to the newer checkout action version to pick up improvements and fixes.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Introduces a committed
manifest.jsonthat is the single source of truth for a runtime release. It is used both ways:setupjob reads[.pythons[].full_version]from it and feeds the build matrix viafromJSON, replacing the hardcoded version list. What gets built is exactly what the manifest lists.publish-releaseinjects thereleasedate (= theYYYYMMDDtag) and uploads the samemanifest.jsonas a release asset.This lets
serious_pythonandfletconsume a single, consistent version set — CPython full version + build date, Pyodide version + platform tag, dart_bridge version, supported short versions — keyed by release date, instead of hand-mirroring versions in multiple places (which had already drifted: e.g. dart_bridge1.2.3on Linux vs1.2.1elsewhere; unified here to1.2.3).Changes
manifest.json(new) — source of truth; committed form omitsrelease..github/workflows/build-python.yml—setupjob derives the matrix from the manifest;publish-releasechecks out, injects the release date, and uploadsmanifest.json.README.md— documents the manifest, the date-keyed release flow, and consumers.After merge
Cut a fresh release via
workflow_dispatch(newYYYYMMDD) to rebuild the pythons and publish the manifest; that date becomes serious_python's pinneddefaultReleaseDate.Per-version build specifics (ABIs, 3.12 vs 3.13+ build method) remain in the platform build scripts.