Palash Debnath
5cab8e0149
Renames what users see. The app, the installers, the window title, the
docs and all 21 locales now say VoiceStudio, with "(previously
OmniVoice-Studio)" noted near the title of each doc surface so people
recognise it.
Deliberately NOT renamed, because renaming any of them silently breaks
an existing install — there is no legacy-path fallback anywhere in this
codebase:
- bundle identifier com.debpalash.omnivoice-studio (MSI UpgradeCode,
macOS TCC grants, managed venv, WebView localStorage, the
single-instance lock)
- data directories OmniVoice / .omnivoice and omnivoice.db
- the ~150 OMNIVOICE_* environment variables
- the X-OmniVoice-* HTTP headers (a wire protocol)
- the published Docker image paths
- the OmniVoice ENGINE, which is a model name and not this product
tests/test_identity_paths_survive_the_rename.py pins every one of those
so a future well-meaning sweep cannot orphan a user's library.
Linux .deb users install a new package name and should apt remove
omnivoice-studio; that note is in the changelog.
78 lines
4.0 KiB
Markdown
78 lines
4.0 KiB
Markdown
# Update channels (Stable / Preview)
|
|
|
|
VoiceStudio auto-updates itself in the background. You choose **which
|
|
builds** it offers you with the update channel in **Settings → Updates →
|
|
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.
|
|
|
|
## Your data during updates
|
|
|
|
Your voices, projects, history, and settings live in a SQLite database
|
|
(`omnivoice.db`) outside the app bundle, so replacing the app never touches
|
|
them. On the **first launch of an updated build**, if the new version needs a
|
|
database schema upgrade, VoiceStudio:
|
|
|
|
1. **Backs up the database first** — a consistent snapshot is written next to
|
|
it as `omnivoice.db.backup-<version>-<n>` before any migration runs. The
|
|
newest **3** backups are kept; older ones are pruned automatically.
|
|
(Databases over 500 MB skip the snapshot, with a log line saying so.)
|
|
2. **Stops instead of guessing** — if a migration fails midway, the app does
|
|
*not* start on a half-migrated database and does *not* silently restore
|
|
anything. It shows an error naming the backup path so you (or a support
|
|
thread) decide: retry, report the issue, or roll back by replacing
|
|
`omnivoice.db` with the backup.
|
|
|
|
**Settings → Updates** shows the timestamp of the latest backup, the release
|
|
notes of any available update, and a **What's new** reader for the shipped
|
|
changelog — all local, no extra network calls.
|
|
|
|
The Python environment (`.venv`) is also updated non-destructively: dependency
|
|
drift after an app update is reconciled **in place** with `uv sync`, and a
|
|
failed sync keeps the previous environment working. The venv is only ever
|
|
rebuilt when its interpreter is *confirmed* broken (structural check + a
|
|
direct probe) or when you explicitly use **Clean & Retry**.
|
|
|
|
## For maintainers — how previews are built
|
|
|
|
Preview builds come from **`main`**, two ways:
|
|
|
|
- **Nightly (automatic).** A scheduled job (07:00 UTC) rebuilds the rolling
|
|
`preview` prerelease from `main` — but only when `main` actually moved in the
|
|
last day, so idle days cost nothing. Preview is never more than ~24h behind
|
|
`main`.
|
|
- **On demand.** **Actions → Desktop Release → Run workflow** on `main`, set
|
|
**publish_preview = true**. Useful to refresh immediately without waiting
|
|
for the nightly. Previews build from `main` **only** (hard rule, owner-set
|
|
2026-07-16) — the preview-gate refuses any other branch; to preview a fix,
|
|
merge it to `main` first.
|
|
|
|
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.
|