20260630

Bump dart_bridge_version to 1.4.1 (#26)

dart-bridge 1.4.1 adds armeabi-v7a binaries for Python 3.13/3.14. Bump the
manifest so the next date-keyed release advertises it to serious_python / flet.

20260629

Build armeabi-v7a (32-bit ARM) for Python 3.13/3.14 (#25)

CPython's official Android/android.py lists arm-linux-androideabi in its
supported HOSTS for both 3.13 and 3.14, and beeware's cpython-android-source-deps
publishes the matching 32-bit dependency tarballs. PEP 738 makes 64-bit Android
the *tested* Tier-3 configuration; it does not prevent building 32-bit ARM. So
the only blocker was a self-imposed ABI gate in build.sh.

- build.sh: allow armeabi-v7a through the 3.13+ official-build ABI case.
- build-all.sh: read android_abis from manifest.json (same source the CI
  packaging step uses) instead of a separate hardcoded version gate, so the
  build set and package set stay in lockstep.
- manifest.json: add armeabi-v7a to 3.13 and 3.14.
- README/android/README: correct the "3.13+ are 64-bit-only" note.

Validated locally: 3.14.6 and 3.13.14 both build via android.py and package
into Dart tarballs; libpython and extension modules are ELF32/ARM with no
import failures.

20260621

darwin/macos: don't explicit-codesign bundled C extensions (keep link…

20260618

Manifest drives Android ABI list (per-minor android_abis) (#21)

Each `pythons.<short>` entry in manifest.json now carries an
`android_abis` array (64-bit first, `armeabi-v7a` trailing on 3.12 only —
PEP 738 dropped 32-bit Android from 3.13). The Android build step in
build-python-version.yml reads it via `jq` and loops
`package-for-dart.sh` once per ABI, replacing the hardcoded
`if version_int < 313 then armeabi-v7a` shell check.

Adding or bumping a Python minor's ABI set is now a one-line manifest
edit; the workflow + downstream consumers (serious_python's
gen_version_tables, flet's manifest-driven registry) flow it through
automatically.

README schema note + the `android_abis` line added to the example.

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

20260614

Add manifest.json as the runtime source of truth (#15)

* Add manifest.json as the runtime source of truth

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.

* Bump actions/checkout to v6 in workflows

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.

20260611

PBS-style date-keyed releases + Node 24 actions (#14)

• 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.

v3.14

Merge pull request #1 from flet-dev/android

Android support

v3.13

Merge pull request #1 from flet-dev/android

Android support

v3.12

Build Python for Android