e58106d552
The Preview update channel was effectively dead: its only build trigger was a manual workflow_dispatch, so "preview = main" was never enforced — the live preview manifest was stuck at 0.3.5-41 (June 7) while main moved to 0.3.7. It also shipped two latent hazards: the `preview` GitHub release had drifted to isPrerelease=false (a non-prerelease `preview` is eligible to become GitHub's "Latest" — the exact URL the *stable* updater reads, so it could hijack the Stable channel), and its updater manifest dropped darwin-x86_64 (Intel-Mac preview users silently got no updates — a cross-platform-parity breach). Changes (release.yml): - Add a nightly `schedule` (07:00 UTC) that rebuilds the rolling `preview` prerelease from main. A new `preview-gate` job no-ops the 4-platform matrix on nights when main didn't move, so idle days cost only a ~30s gate job. - Centralize the preview-vs-stable decision in `preview-gate.outputs.is_preview` (schedule OR workflow_dispatch+publish_preview), consumed by the stamp step, tauri-action, and preview-notes — replacing the repeated inline conditions. - Harden the prerelease flag: preview-notes' `gh release edit` now re-asserts `--prerelease` every run, and a new post-publish step fails the run if the preview release isn't a prerelease or its manifest is missing any platform stable ships (catches the Intel-Mac regression in CI). Docs (docs-sync): update docs/update-channels.md — previews are no longer "manual / no scheduled spend"; they build nightly from main (+ on demand). The live `preview` release was re-flagged prerelease out-of-band to close the hazard immediately; this makes it recurrence-proof. Co-authored-by: mergetest <test@local> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2.4 KiB
Update channels (Stable / Preview)
OmniVoice Studio auto-updates itself in the background. You choose which builds it offers you with the update channel in Settings → About → Update channel.
| Channel | What you get | Who it's for |
|---|---|---|
| Stable (default) | The latest tagged vX.Y.Z release. |
Everyone. This is the default on every install and every launch. |
| Preview | The latest main build (a rolling preview prerelease). Newer features, less testing. Falls back to a stable release if one is ahead. |
Users who want to try fixes/features before they're tagged, and report issues. |
Switching is instant — the next update check (on launch, or via Check for updates) uses your chosen channel. Your projects, voices, settings, and any in-flight job are untouched; an in-progress dub blocks the install until it finishes, and your data lives outside the app bundle, so an update never touches it.
There are no accounts, no telemetry, and no extra network calls — both channels just point the existing signed updater at a different GitHub Releases manifest:
- Stable →
releases/latest/download/latest.json - Preview →
releases/download/preview/latest.json
Both manifests are signed with the same minisign key, so a tampered build is rejected regardless of channel.
For maintainers — how previews are built
Preview builds come from main, two ways:
- Nightly (automatic). A scheduled job (07:00 UTC) rebuilds the rolling
previewprerelease frommain— but only whenmainactually moved in the last day, so idle days cost nothing. Preview is never more than ~24h behindmain. - On demand. Actions → Desktop Release → Run workflow, pick a branch
(usually
main), set publish_preview = true. Useful to cut a preview off a feature branch, or to refresh immediately without waiting for the nightly.
Either way it builds the matrix and publishes/updates a single rolling
preview prerelease — always flagged prerelease, and carrying the same
platform set as stable (both verified in CI after each preview publish) — with
its own signed latest.json. The tagged latest stable release is never
affected. Preview users get the new build on their next check; stable users see
nothing.
To stop offering previews, delete the preview release/tag on GitHub — the
Preview channel then falls back to stable.