Updater Workflow

Signed-artifact channel metadata, version checks, platform verification, and rollback rules for production Ricochet releases.

docs/reference/guides/updater-workflow.html
docs/wiki/updater-workflow.html
Ricochet stack and MVC flow Value::String Value::Map Value::Class Value::Block bytecode VM Controller View Postgres $name "home/index" swap view [ ... ] "methodName" Method

Ricochet's production updater workflow is channel metadata plus platform verification. The v1 beta does not ship a self-replacing rco update command; installers, package managers, or a future elevated desktop updater can consume the same metadata without moving risky install privileges into the Ricochet runtime.

Channel Metadata

Production stable tag releases publish UPDATE-CHANNEL-stable.json beside the release artifacts and require platform signature/notarization verification. Semver prerelease tags such as v0.1.19-rc.3 publish UPDATE-CHANNEL-candidate.json, are marked as GitHub prereleases, and record SHA-256 verification metadata for dry-run signed candidate artifacts. The file uses schema ricochet.update-channel version 1 and is written by:

pwsh -NoProfile -File ./scripts/write-update-channel.ps1 `
  -DistDir dist `
  -Channel candidate `
  -Version 0.1.19-rc.3 `
  -ReleaseTag v0.1.19-rc.3 `
  -ReleaseUrl https://github.com/BARKx4/Ricochet/releases/tag/v0.1.19-rc.3

The channel document records release identity, rollout percentage, rollback policy, target manifests, primary artifacts, checksum files, signing reports, optional notary reports, required verification methods, and per-artifact SHA-256 metadata.

Validate channel metadata before publishing it:

pwsh -NoProfile -File ./scripts/validate-update-channel.ps1 `
  -DistDir dist `
  -Channel candidate `
  -Version 0.1.19-rc.3 `
  -RequireProduction

The release workflow writes and validates the channel document before writing the combined SHA256SUMS.txt, so the channel file is also included in the final release checksum bundle.

Update Check Contract

A Ricochet-compatible updater fetches the channel over HTTPS, requires the expected schema and channel such as stable or candidate, rejects older or equal versions unless an operator explicitly chooses a rollback, selects the local platform target, downloads the referenced manifest and artifacts, verifies all SHA-256 values, then runs platform verification before install.

  • Windows: Authenticode verification on the portable ZIP executables and installer.
  • Linux: detached GPG signature verification for the tarball and Debian package.
  • macOS: codesign verification for extracted binaries plus NOTARY-<target>.json with Apple notarytool status Accepted.

Installers should stage the new install outside the active installation path and keep a backup of the previous install until the new rco --help or a stronger product smoke test succeeds.

Rollback Story

Automatic rollback means reverting from a failed staged install back to the previous local install. It does not mean silently downgrading from the public channel.

By default, channel consumers reject older or equal versions. Manual rollback uses the immutable GitHub release for the desired older version, then repeats the same manifest, checksum, signature, and notarization checks before installing.

Updater state should live outside Ricochet VM images, application state, and project workspaces. Ricochet scripts should not delete an existing installation unless the updater has already staged and verified the replacement.