Surfaced by review of #704.
browserState.version in src/api.ts is a hand-maintained copy of the package.json version. It is what the browser/jsdom fallback path reports (used by npm run tauri dev UI work and by the tests), so every release preparation must remember to edit it, and the release workflow's Verify source versions step does not cover it: a missed bump ships silently and shows the previous version in the sidebar badge and the Updates panel under that path.
Fix
Inject it at build time so the bump cannot be missed:
// vite.config.ts
import pkg from "./package.json";
export default defineConfig({ define: { __APP_VERSION__: JSON.stringify(pkg.version) }, ... });
// src/api.ts
version: __APP_VERSION__,
with a declare const __APP_VERSION__: string; in a .d.ts. That reduces each release bump to the files CI already verifies. The tests/config.rs literal is deliberately left alone: it pins the promoted identity and fails on drift, which is its job.
Deliberately not folded into #704, which stays a pure version sync like every previous release preparation.
Surfaced by review of #704.
browserState.versioninsrc/api.tsis a hand-maintained copy of thepackage.jsonversion. It is what the browser/jsdom fallback path reports (used bynpm run tauri devUI work and by the tests), so every release preparation must remember to edit it, and the release workflow'sVerify source versionsstep does not cover it: a missed bump ships silently and shows the previous version in the sidebar badge and the Updates panel under that path.Fix
Inject it at build time so the bump cannot be missed:
with a
declare const __APP_VERSION__: string;in a.d.ts. That reduces each release bump to the files CI already verifies. Thetests/config.rsliteral is deliberately left alone: it pins the promoted identity and fails on drift, which is its job.Deliberately not folded into #704, which stays a pure version sync like every previous release preparation.