You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Date-keyed releases (PBS-style): full version in filenames
Restructures the publish step so that a manually triggered workflow_dispatch
with a `release_date` input (YYYYMMDD) produces a single GitHub release
tagged by that date, containing every per-platform tarball from every
matrix entry. Mirrors what astral-sh/python-build-standalone already does
and what we already consume in flet-dev/serious-python's package_command
via _release.standaloneReleaseDate.
Why move away from one-release-per-python-minor:
* Re-cutting a release for a build fix (e.g. the Python.app strip we
just landed) currently has to clobber an existing tag, which breaks
reproducibility for any downstream that pinned to it.
* Several platform fixes in the past month had to wait for a coordinated
"all minor versions get a fresh tarball" moment; date tags decouple
that — we just cut a new date once everything we care about builds.
* Symmetric with how flet-dev/serious-python's package_command resolves
its astral-sh CPython tarball: pin a date, not a minor.
Changes:
* build-python.yml:
- workflow_dispatch gains a `release_date` input (YYYYMMDD).
- New publish-release job downloads ALL matrix artifacts and
publishes one release tagged ${release_date}.
- Publish only fires on workflow_dispatch with a non-empty
release_date; pushes still exercise the matrix (artifacts left
for inspection) but don't touch releases.
* build-python-version.yml:
- Removed the per-version publish-release job (moved to parent).
- Matrix artifact upload names now include the full Python version
(e.g. python-darwin-3.14.6 instead of python-darwin-3.14) so the
parent workflow can ingest multiple patch versions of the same
minor without artifact-name collisions.
- Darwin packagers receive the full version directly so their
tarball filenames carry it verbatim.
* Per-platform packagers (darwin/ios, android, linux, windows):
- Tarball/zip filenames switch from $PYTHON_VERSION_SHORT to the
full $PYTHON_VERSION (e.g. python-macos-dart-3.14.6.tar.gz). The
internal lookups that need the short version derive it inline.
- mobile-forge artifacts follow the same naming convention.
Consumer side (serious-python's prepare_*.sh, build.gradle, CMakeLists)
still needs a follow-up to:
- Read a new PYTHON_BUILD_RELEASE (YYYYMMDD) env var instead of using
"v$PYTHON_VERSION" as the release tag.
- Reference tarballs by full Python version in the URL.
- Lay them out as $FLET_CACHE_DIR/python-build/<release>/<file>.
That migration is independent of this PR and will land separately.
* ci: bump actions/{checkout,upload-artifact,download-artifact} v4 -> v5
The previous releases bundled Node.js 20 runtimes; GitHub deprecated
Node 20 in actions on 2026-06-16 with full removal on 2026-09-16, and
the workflow now emits a "Node.js 20 actions are deprecated" warning
on every matrix entry. v5 ships on Node 24 across all three actions
and is otherwise drop-in compatible with our usage.
setup-python is already on v6 (Node 24 native). softprops/action-gh-
release@v2 still runs on Node 20 — leaving it pending an upstream v3
since it only fires on the new workflow_dispatch publish path and
won't add warning noise to push-driven runs.
* ci: bump actions to latest majors (Node 24)
The earlier v4->v5 bump didn't silence the Node 20 deprecation warnings:
actions/upload-artifact@v5 and actions/download-artifact@v5 only have
"preliminary" Node 24 support and still default to Node 20. The runtime
default flips to Node 24 only at v6+. Move every action to its current
latest major (all node24):
actions/checkout v5 -> v6
actions/upload-artifact v5 -> v7
actions/download-artifact v5 -> v8
softprops/action-gh-release v2 -> v3
actions/setup-python v6 (already latest, node24)
All inputs in use remain supported; artifacts stay zipped so upload v7 /
download v8 (direct-upload/decompress changes) and download v8's default
digest-mismatch=error don't affect this workflow.
0 commit comments