v0.2.0: Check for Updates everywhere + popover Settings shortcut#19
Conversation
Adds the macOS-standard "Check for Updates…" item to both the Stint app menu (between About and Settings) and the tray right-click menu. Both entries open the main window, navigate to /settings, and fire a \`check-for-updates\` Tauri event. A module-level signal in ui/src/lib/updates.ts (\`checkRequested\`) bridges the event to UpdatesPanel: App.tsx's listener calls \`requestCheckForUpdates()\` on receipt, which increments a counter that UpdatesPanel watches via createEffect. Using a module-level signal rather than a per-component one means the request lands even if the panel mounts after the event arrives — createEffect runs on first mount with the current counter value. Also: when the manifest's notes field is the placeholder string "see CHANGELOG.md", render it as an actual link to the GitHub CHANGELOG.md at the right release tag rather than dumping plain text. Custom notes (anything other than the placeholder) still render as a \`<pre>\` block, leaving room for richer notes later.
Adds a small emerald pill ("v0.2.0 available") next to the version
field in the About page identity card. Passive — clicking it doesn't
do anything; it's strictly informational. Consumes the existing
\`useUpdateBanner()\` signal so it shares the 24h auto-poll cadence
rather than introducing a new check.
The About page is low-frequency, so making the badge clickable would
feel off — it's a "what is this app" surface, not an action surface.
Users who want to act on the update have the top-of-window banner,
the menu/tray "Check for Updates…" entries, and the popover indicator.
Two additions to the popover, both targeting the same gap: popover users rarely open the main window, so neither the top-of-window update banner nor the existing "Open Stint →" affordance reaches them effectively. 1. Cogwheel button in the footer (between "Open Stint →" and "Solidtime ↗") that opens the main window and emits a navigate event to /settings. Same effect as menu/tray "Settings…" entries from inside the popover. 2. Conditional "Update available: vX.Y.Z → open Settings" link as a one-line row above the footer. Only renders when \`useUpdateBanner()\` reports an available update. Click → same path as the cogwheel: main window + /settings. The popover and main window are separate webview contexts in Tauri, so each runs its own \`useUpdateBanner\` polling instance. Bandwidth impact is trivial (one GitHub fetch per 24h per window) and the duplication keeps the code simple — no cross-webview signal sharing.
Adds a dev-only escape hatch in check_for_updates: when the \`STINT_DEV_VERSION_OVERRIDE\` env var is set to a valid semver string, short-circuits the network check and returns synthetic \`available: true\` data. Lets a maintainer preview the new update affordances — About badge, popover indicator, Settings panel state machine — without editing tauri.conf.json or shipping a fake release. Usage: STINT_DEV_VERSION_OVERRIDE=0.0.1 scripts/dev-app.sh \`install_update\` is deliberately NOT mocked. Clicking Install while the override is active hits the real updater and fails with "no update available" since the actual running version equals the manifest version. That's correct — don't let the preview path accidentally exercise the real install on a dev build. Adds semver = "1.0" as a stint-app dep (gated on the updater feature) for parsing the env var. Tauri's updater stack already pulls semver transitively, so no net dependency change.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 5fa29450c0
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if (checkRequested() > 0) { | ||
| void check(); |
There was a problem hiding this comment.
Consume check requests instead of replaying them on every remount
checkRequested is treated as a permanent boolean (> 0) rather than a consumable counter, so after the first menu/tray-triggered request this effect will call check() on every future UpdatesPanel mount even when no new request happened. In practice, opening Settings later will keep issuing unexpected network update checks and UI state flips from stale requests; the panel should track the last handled counter value (or reset/consume it) so only new increments trigger checks.
Useful? React with 👍 / 👎.
|
🎉 This PR is included in version 0.2.0 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
Summary
Surfaces the auto-updater across every entry point a user might reach for it, plus a Settings shortcut from the popover.
Four commits:
Three `feat:` + one `chore:` → semrelease cuts v0.2.0 (minor bump, fitting "Phase 4 complete" milestone).
Test plan
Merge via "Create a merge commit" per standard.