Staying current

The standalone binary updates itself. No package manager required, nothing to re-download by hand.

Check first

cherry upgrade --check --json

{
  "ok": true,
  "command": "upgrade",
  "data": {
    "current": "0.1.0-rc.1",
    "target": "v0.2.0",
    "asset": "cherry-linux-x86_64",
    "status": "outdated"
  }
}

--check touches nothing and works everywhere, even under mix, where the swap itself is refused (library users upgrade with mix deps.update cherry, and the error says exactly that).

Upgrade

cherry upgrade

What happens, in order:

Resolves the latest stable GitHub release; prereleases never arrive uninvited.
Downloads this platform's binary from the release.
Verifies it against the release's SHA256SUMS. Any mismatch or missing entry aborts with the current binary untouched. There is no override flag, by design.
Swaps the executable in place: write beside, rename out, rename in. The running image is never overwritten.

upgraded cherry 0.1.0-rc.1 → 0.2.0

Note

Tracking a release candidate on purpose? cherry upgrade --version v0.2.0-rc.1 targets any tag, prereleases included.

Warning

On Windows the replaced executable lingers beside the new one as cherry.exe.old, because the OS keeps the running image locked. It's harmless, safe to delete, and the next upgrade reuses it.

Provenance all the way down

The same guarantees hold at install time: install.sh and install.ps1 verify their download against SHA256SUMS before installing, and every release binary carries GitHub build-provenance attestation. The binary you run is, verifiably, the binary CI built from the tag.