Skip to content

Say exporter-v where the release files still said macos-exporter-v #70

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
parawanderer merged 1 commit into from
Aug 15, 2026
Merged

Say exporter-v where the release files still said macos-exporter-v #70

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 5 additions & 1 deletion CONTRIBUTING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -402,7 +402,11 @@ python scripts/add_strings.py --check # fail if any locale is missing on

## Running the export wizard on a Mac

Testing an export means a real Mac signed into iCloud, usually a VM. A fresh macOS install
**This covers the macOS-local route only.** Exporting through iCloud needs no Mac and no VM —
see [Running the exporter from the CLI](./docs/how-to-export-with-the-cli.md). What follows is
for testing the path that reads Find My's own files, which still runs on macOS and nowhere else.

Testing that export means a real Mac signed into iCloud, usually a VM. A fresh macOS install
has **neither git nor python3** — both arrive with the Xcode Command Line Tools — so
`scripts/bootstrap_macos.sh` does the lot: installs the tools, clones, creates a virtualenv,
installs the dependencies and launches the wizard. It is safe to re-run.
Expand Down
5 changes: 3 additions & 2 deletions python/exporter/version.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,8 +4,9 @@
**This is the single source of truth** - see rule 9 in AGENTS.md. It reaches the wizard's window
title and, more importantly, every export as `via: <producer>:<version>`, which is how anyone
looking at a zip afterwards works out what built it. Releases are tagged
`macos-exporter-v<this>`, and `scripts/release_version.py` refuses to publish a release whose tag
disagrees.
`exporter-v<this>` - `macos-exporter-v` is the older spelling and still resolves, because tags
already published keep their name - and `scripts/release_version.py` refuses to publish a release
whose tag disagrees.

**It lives here rather than in wizard.py so that reading it costs nothing.** The CLI is headless
and the release check runs on a lint runner; importing the wizard for a version string would pull
Expand Down
6 changes: 5 additions & 1 deletion scripts/release_version.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -39,9 +39,13 @@

Check a release tag against it. Accepts a bare tag or a full ref, so `$GITHUB_REF` works:

python scripts/release_version.py --kind exporter --tag macos-exporter-v1.0.5
python scripts/release_version.py --kind exporter --tag exporter-v1.1.0
python scripts/release_version.py --kind android --tag refs/tags/android-app-v1.0.5

The exporter also answers to `macos-exporter-v`, which is what its tags were called while it
only ran on macOS. Published tags keep their names, so that spelling has to keep resolving -
but it is not the one to reach for when tagging something new.

On success it prints the version, so a workflow can use it directly:

APP_VERSION="$(python scripts/release_version.py --kind android --tag "$GITHUB_REF")"
Expand Down
Loading