Release Manifest
The Release Manifest is the machine-readable source of truth for a public release. The download page, release notes, updater, About screen, diagnostics, and support pages must ultimately resolve version, stream, build number, Git commit, publisher, and artifact hashes from the same record.
The website currently publishes a separate unreleased readiness record, not a signed published-release manifest. Read the Release Manifest page, inspect the readiness JSON and its readiness schema, or review the byte-identical published Release Manifest v1 schema and latest pointer v1 schema.
Required current state
| Field | Current value | Meaning |
|---|---|---|
state | unreleased | The target version has not been published |
downloads.enabled | false | The website cannot expose installer links |
artifacts | [] | No verifiable public artifact exists |
claims.release | [] | No release claim has been unlocked |
update.enabled | false | This is not an updater endpoint |
security.signatureRequired | false | The current record does not pretend to be a signed release record |
The target version may be 1.0.0, but formal version, build number, publication time, source commit, tag, and legal publisher remain absent until the final bytes and responsible publisher exist. Unknown facts must not be filled with TBD, invented URLs, zero hashes, fake signing identities, or future dates.
What a published record adds
A published record requires at least:
- a cleared brand, real legal publisher, and official website;
- full version, build number, monotonic sequence, signed tag, and clean commit and tree;
- immutable artifact URLs, exact sizes, SHA-256 values, operating systems, architectures, and minimum versions;
- macOS Developer ID, Team ID, notarization, stapling, and Gatekeeper evidence;
- component receipts from the final package, an SBOM, and provenance;
- bilingual release notes, known issues, system requirements, verification guidance, privacy, license, support, and security entry points;
- storage schema, tested upgrade sources, backup rules, and downgrade policy;
- a detached JWS signature over RFC 8785 canonical JSON.
Release and update layers
A future public release should use an immutable version manifest and a detached signature. Each update stream should then reference it through a separately signed, monotonically increasing latest pointer. The manifest freezes that release's initial sequence and initial rollout snapshot; the pointer carries an independent control-plane sequence plus the current rollout state and percentage. Its first reference cannot be lower than the manifest sequence, and every renewal, expansion, pause, resume, or withdrawal must use a strictly higher pointer sequence. A pointer for the same release also keeps the same cohort seed so increasing a staged percentage preserves the users already selected. Publication order is: immutable artifacts → immutable manifest and signature → atomic update-pointer switch.
The current record is not exposed through an updater's public latest endpoint. A disabled button is not merely visual state; it follows from manifest validation.