Release Waveform
Waveform ships four things: the waveform CLI (through Silicon Apps, and as waveform-cli on crates.io), the Rust
client silicon-waveform-client (crates.io), the service waveform-api (on the Waveform host) and the website (a
container on the same host). Nothing in this repository publishes or deploys by itself: every upload and deployment
below is a reviewed step a Carbon runs.
Versions
- The CLI's version (
cli/Cargo.toml), itsapps.yamlversion and the release tag (vX.Y.Z) are always equal; the release workflow refuses a tag that differs. - While Waveform is 0.x, a breaking change raises the minor version (0.5 → 0.6). The client and CLI stay on the same minor, because the CLI depends on the client by version.
- The HTTP path stays
/api/v1; the contract version (X-Waveform-Contract-Version,GET /api/contracts) records breaking changes and the compatibility matrix (API compatibility).
Build the CLI packages
- Update the versions and the bundled guides (
python3 scripts/sync-cli-docs.py), then check them:python3 scripts/sync-cli-docs.py --check. - Push the tag
vX.Y.Z(or run the Build Silicon Apps release workflow by hand). For each target it builds the CLI with the pinned toolchain (static musl on Linux), runs the CLI tests, then packs the target on its own runner withscripts/package-apps.sh, which runswaveform --help,waveform accounts --jsonandwaveform login status --jsonin an empty home beforesilicon-apps validateandsilicon-apps pack. - Download the workflow artifact
waveform-silicon-apps-release: one archive per target,waveform-X.Y.Z-<target>.tar.gz, each with its.sha256, andSHA256SUMS. - Optionally run Verify Linux CLI on Amazon Linux 2023 with the release run id and source revision: it runs the three commands from the Linux archives on the oldest Linux the Silicons use.
Each archive holds apps.yaml, listing only its own target, and bin/waveform (bin/waveform.exe on Windows). The
targets are linux-x86_64, linux-aarch64, windows-x86_64, windows-aarch64, macos-x86_64 and macos-aarch64.
To package one build on your own machine:
cargo build --release --locked --manifest-path cli/Cargo.toml
scripts/package-apps.sh 0.6.0 macos-aarch64 cli/target/release/waveform
It needs Python 3.9+ and silicon-apps 0.2 (cargo install --locked silicon-apps-cli --version 0.2.0), writes
dist/apps/waveform-0.6.0-macos-aarch64.tar.gz and its .sha256, and refuses a binary that is not native for the
target, a dynamically linked Linux binary, or one that answers the three commands wrongly. A binary this machine
cannot run is packed with a note: the Silicon Apps validation worker for its target runs the commands at upload.
Publish
Silicon Apps validates uploads on its Linux workers today (linux-x86_64, linux-i686, linux-aarch64,
linux-armv7hf). Upload the two Linux archives; keep the macOS and Windows archives for when their workers go live
(a release's packages cannot change afterwards, so those targets join a later release).
silicon-apps upload waveform --target linux-x86_64 waveform-0.6.0-linux-x86_64.tar.gz
silicon-apps upload waveform --target linux-aarch64 waveform-0.6.0-linux-aarch64.tar.gz
silicon-apps packages waveform
silicon-apps release waveform --version 0.6.0 --package <linux-x86_64 package id> --package <linux-aarch64 package id>
silicon-apps install 'waveform>dev' # check the development release on a Linux machine
silicon-apps promote waveform <development release id> --version 0.6.0
Then publish the Rust crates, the client first (Cargo resolves the CLI's client dependency from crates.io):
cargo publish --manifest-path client/Cargo.toml
cargo publish --manifest-path cli/Cargo.toml
Installed copies update within about a minute of a production release: Silicon Apps' updater checks every minute, and
waveform never updates itself. A bad release is withdrawn with
silicon-apps withdraw waveform <release id> --reason "…"; installs move to the previous good release.
Deploy the service and the website
Build the native bundle with the Build native backend bundle workflow and deploy it with
deploy/native: upgrade.py for a release, install-frontend.py for the website's
image. The 0.6.0 release moves to Silicon Accounts once, with accounts_cutover.py, in the order the
cutover runbook gives.
0.6.0: Silicon Accounts and Silicon Apps
Breaking for every consumer. The service, client and CLI are 0.6.0; the API path stays /api/v1 with contract 2.0.0.
- Sign-in. Silicon Accounts is the only identity. Carbons sign in to the CLI with
waveform login(device flow) and to the website with the hosted sign-in pages; Silicons hand over a short-lived token (silicon-accounts login --app waveform -q | waveform login --slt-stdin). The service has no sign-in routes: it checks Silicon Accounts access tokens itself. Every machine signs in again once. - Your account. Everything belongs to the account that made it. A Carbon reads and manages the history, settings,
provider keys and Briefcase access of the Silicons it looks after (
--account si:<id>,?account=), and never runs speech as them. - Other apps call Waveform for an account with Silicon Accounts User verification proofs (
waveform.tts,waveform.stt), from the apps allowed inWAVEFORM_PROOF_ISSUERS. - Briefcase. Waveform reaches each account's Briefcase files with User verification proofs. When Briefcase cannot
take the audio, TTS still completes and Waveform holds the MP3 for the idempotency retention (
audio_url,storage.reason). - Account events arrive signed at
POST /webhooks/accounts. - Distribution. Silicon Apps installs and updates the CLI (
silicon-apps install waveform); the CLI has no updater. - Rust client. Sign-in moved to
signin::SignIn;AuthisAnonymous,BearerorProof; methods take no workspace or actor parameters (for_accountselects a Silicon you look after);TtsResponseaddsaudio_urlandstorage. See the client guide. - CLI. Flags and commands of the earlier sign-in, test-environment and update model fail with exit 2 and name what
replaced them;
provider-key-set|deletebecameprovider-keys set|deleteandstorage start|completebecamestorage approve.
Releases before 0.6.0: docs/history/releases-0.2-0.5.md.