Artifact verification and channel promotion
EvoX Desktop follows main → Pre → Beta → Stable. Promotion fixes the source revisions of a published candidate; it must not include newer changes from main.
Distinguish public availability from native channels
The website Stable download entry permits fallback to Beta through manifest resolution. Record both requested and resolved channels; opening the Stable page does not establish a native Stable release. The website native-channel check uses --require-native-channel to require a valid manifest from the requested channel itself. Record availability and native-channel acceptance separately.
Sources and gates
| Stage | Source | Release conditions |
|---|---|---|
| Pre | Freshly fetched main at release time | Officially signed artifacts for the platforms in scope, with verified provenance, digests, and manifests. |
| Beta | One explicitly selected, published Pre | Both Desktop and kernel locked to that Pre’s immutable tag revisions, with applicable release gates passed. |
| Stable | The latest accepted Beta | Its exact revisions, complete required CI, platform coverage, and release audit gates. |
All channels use the same production build recipe, signing, notarization, and updater identity. Pre/Beta allow separate platform deliveries, never delivery of a platform with failed signing. Stable desktop must cover macOS arm64, macOS x64, and Windows x64.
Fix provenance and recheck delivery
Promotion fixes the candidate's code source; changing channels does not authorize additional code. Verify the installers, signed manifests, and public entry points actually delivered. Identical source does not replace final-byte verification, and verified bytes do not replace channel-pointer checks.
| Layer | Question | Evidence |
|---|---|---|
| Candidate source | Is it the selected Pre or Beta commit? | Tag, full SHA, release record |
| Installer | Is it the final artifact for the correct platform? | Final URL, digest, signature, platform validation |
| Channel manifest | Does it reference a complete same-version set? | Manifest version, platform slots, resolution result |
| User entry point | What version do download and update actually serve? | Requested channel, resolved channel, actual version |
Scenario: Beta artifacts exist but the website serves an older version
Distinguish individual Release artifacts from public updates. A Pre/Beta platform can finish while the public pointer remains on the previous complete version. Check whether all three required desktop targets are complete at the same version. An incomplete set is awaiting delivery, not automatically a website-cache fault.
After completion and pointer switching, check versions and bytes through final entry points. For Stable requests, also record any resolution to Beta. Successful download establishes availability; native-channel acceptance requires a valid manifest from the target channel itself.
Verify each candidate artifact
- Fix the source repository, full commit SHA, version, and target architecture.
- Inspect the actual installer’s signing identity and platform verification results.
- After upload, download from its final URL and check filename, size, and SHA-256.
- Verify that the signed manifest matches those bytes, the platform, and the channel.
- Record machine checks separately from actual installation, launch, and update exercises. Never mark an unperformed manual step as passed.
A macOS result does not cover Windows. A DMG result does not cover PKG.
Installer delivery versus update availability
A successful single-platform Pre/Beta installer is downloadable from its GitHub Release. The desktop update manifest remains in staging until both macOS architectures and Windows x64 are published at the same version. Until then, in-app updates and the website offer the previous complete release.
Artifact existence, successful platform verification, and public update availability are separate states. Verify each.
Blockers and recovery
Stop promotion when source, version, or platform does not match. A failed signature, digest, or notarization blocks delivery for that platform. Missing required platforms or checks block Stable.
A Beta code fix must enter main, become a new Pre, and then be promoted to a new Beta. Do not overwrite immutable tags or published files. Restoring a channel pointer does not automatically downgrade clients that already updated; verify recovery separately.
Determine whether promotion is complete
Retain the candidate tag and commit, platform verification records, approval record, and manifest results after the pointer change. Check GitHub Release artifacts, public downloads, and application updates separately, recording requested channel, resolved channel, and actual version.
If public entry points still serve the previous complete version, record the candidate as delivered but not available through public updates. Failed checks block further promotion. Repair the candidate or roll back the pointer through the release procedure, then check final entry points again. A finished pipeline alone does not establish completion.