Release Remind#

Silicon Apps distributes Remind and keeps every installation up to date; remind never updates itself. Silicons install it with silicon-apps install remind (development releases: silicon-apps install 'remind>dev'), and the Silicon Apps updater moves installed copies to new releases within about a minute. The Rust client is an ordinary Cargo dependency, published to crates.io separately.

What a release is#

The release version is the CLI version in crates/cli/Cargo.toml (0.6.0 at the move to Silicon Accounts). Each target ships as its own archive, dist/apps/remind-<version>-<target>.tar.gz, holding the binary at bin/remind (bin/remind.exe on Windows) and an apps.yaml that lists only that target:

schema_version: 1
app_id: remind
version: 0.6.0
command: remind
targets:
  linux-x86_64:
    binary: bin/remind

Remind ships linux-x86_64 and linux-aarch64 (what the Silicon fleet runs; built with a glibc 2.28 baseline), macos-x86_64, macos-aarch64, windows-x86_64 and windows-aarch64. Only the Linux validation workers are live on Silicon Apps today; the macOS and Windows archives are built and kept for when their workers go live.

Every binary must answer three commands#

Silicon Apps runs these signed out, in a clean environment, on every target, and refuses a package whose binary fails one of them. Check them yourself in an empty home:

mkdir -p /tmp/empty && env -i HOME=/tmp/empty SILICON_HOME=/tmp/empty ./remind --help
env -i HOME=/tmp/empty SILICON_HOME=/tmp/empty ./remind accounts --json      # contains "app_id":"remind"
env -i HOME=/tmp/empty SILICON_HOME=/tmp/empty ./remind login status --json  # {"authenticated":false}

All three exit 0, need no network, and write nothing.

Build and pack#

The release workflow (.github/workflows/release.yml) runs on a v<version> tag (it must equal the CLI version) or by hand. It builds and tests each target on a native runner (Linux with cargo zigbuild at the glibc 2.28 baseline) and checks the binary there with scripts/package-apps.sh --check-only: the native format, the glibc baseline, and the three commands above in an empty home. One Linux job then packs every target with scripts/package-apps.sh <version> <target> <binary>, which stages apps.yaml and the binary, runs silicon-apps validate and silicon-apps pack (the packer comes from cargo install --locked silicon-apps-cli@0.2.0), and checks the archive holds exactly those two files. The archives and their SHA256SUMS are kept as the workflow artifact remind-silicon-apps-release. The workflow publishes nothing.

To build and pack on one Mac instead (Xcode, cargo-zigbuild with Zig 0.15, and cargo-xwin with LLVM's clang-cl and lld-link):

python3 scripts/build-release.py                                  # all six targets into dist/apps/
python3 scripts/build-release.py --targets linux-x86_64,linux-aarch64
scripts/package-apps.sh 0.6.0 macos-aarch64 target/release/remind  # pack one binary you built

The script refuses a binary built for another target, a Linux binary that needs a glibc newer than 2.28, and a binary that answers the three commands wrongly or writes to its home. Packing the same binary twice gives the same archive, byte for byte.

Publish (a Carbon's step)#

An author of the remind app uploads each archive to Silicon Apps, creates a development release from the packages, checks it, then promotes it to production:

silicon-apps upload remind --target linux-x86_64 dist/apps/remind-0.6.0-linux-x86_64.tar.gz
silicon-apps upload remind --target linux-aarch64 dist/apps/remind-0.6.0-linux-aarch64.tar.gz
silicon-apps packages remind
silicon-apps release remind --version 0.6.0 --package <package_id> --package <package_id>
silicon-apps promote remind <release_id> --version 0.6.0

Publish the crates in dependency order: silicon-remind-client, then silicon-remind-cli.