Palash DebnathandClaude Opus 4.8
672f106f05
Adds a user-selectable updater release channel (Settings -> About -> Update channel). Stable (default, every install + launch) tracks tagged vX.Y.Z releases; Preview tracks the latest main build via a rolling "preview" prerelease, falling back to stable if a stable release is ahead. Why Rust: tauri-plugin-updater reads its endpoints from tauri.conf.json and neither the JS check() nor the plugin's registration Builder can change them at runtime (verified against the 2.10.1 source). The only runtime-endpoint API is UpdaterExt::endpoints, so check+install move into two Rust commands that mirror the plugin's own check/download_and_install -- the Stable path behaves identically to the JS flow it replaces; only which manifest is consulted changes. Switching is instant (channel is read per check), no restart. backend (Rust): - config.rs: update_channel field (default "stable", VALID_CHANNELS) + get/set_update_channel commands. - updater_channel.rs: channel_endpoints() (preview -> [preview, stable]) + check_update / install_update commands; install emits update://progress. frontend: - utils/updateChannel.js (+test): single source of truth, normalizeChannel. - utils/updater.js: routes the badge flow (#198) through the Rust commands via the same store contract -- UpdateBadge/App.jsx unchanged. - Settings About: Stable/Preview segmented toggle, channel-aware endpoint row + diagnostics; Check-for-updates honors the live channel. - i18n en + zh-CN. release.yml: additive, workflow_dispatch-guarded preview publish to a rolling "preview" prerelease. The v* tag-push stable path evaluates to its exact prior values (verified) and is never affected. Preview builds are manual -- no scheduled CI spend, nothing auto-published. docs/update-channels.md. Verified: cargo check (compiles clean), tsc, vitest 162/162, build, CJK guard, release.yml YAML parses. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2.0 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 — cutting a preview build
Preview builds are manual (no scheduled spend, nothing auto-published):
- Go to Actions → Desktop Release → Run workflow.
- Pick the branch to build (usually
main). - Set publish_preview = true and run.
This builds the matrix and publishes/updates a single rolling preview
prerelease 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.