the_og/better-claude-config
1
0
Fork 0
Code Issues 8 Pull Requests 3 Actions Packages Projects Releases 4 Wiki Activity

Update checker: notify when a newer release is available (no auto-update) #19

New Issue
Closed
opened 2026-07-04 16:36:16 -04:00 by the_og · 1 comment
the_og commented 2026-07-04 16:36:16 -04:00
Owner
Copy Link
Copy Source

Problem

Users have no way to learn that a newer release exists — they'd have to manually visit the releases page. We ship versioned releases (v1.1.0 now) via the tag-triggered release.yml, but nothing tells an installed copy it's out of date.

Proposed solution

A lightweight update check that notifies only — it does NOT download or replace the binary (deliberate: self-replacing unsigned PyInstaller bundles is a Gatekeeper/file-lock headache we're avoiding).

  • Query the latest release, compare its version to the running __version__, and if newer, show a non-blocking notification (banner or dialog) with a link to the release/download page.
  • Manual trigger: a "Check for updates" button (in the About dialog). Reports "up to date" or "vX.Y.Z available".
  • Optional auto trigger: a quiet, throttled check on startup (e.g. at most once/day via QSettings timestamp), off-thread, that silently does nothing on failure/offline. Must be disableable in settings.

Design notes / prerequisites

  • Release source must be publicly reachable. The repo is currently private, so the Gitea releases API (GET /api/v1/repos/the_og/better-claude-config/releases/latest) returns 401 to an anonymous, distributed app. Before this ships, either make the repo (or at least a releases/version manifest) public, or host a small public version.json. Do NOT embed a Gitea token in the distributed app. Verify this first — it blocks the feature.
  • Version compare belongs in bcc_core.py as a pure, unit-testable function: strip a leading v, compare numeric tuples (e.g. (1,1,0)), handle pre-release/garbage gracefully. Don't string-compare ("1.10.0" < "1.9.0" lexically is wrong).
  • Network off the UI thread (QThread), short timeout, fail quiet. No crash offline.
  • Reuse the __version__ single source of truth from the About-page issue.

Acceptance criteria

  • Manual "Check for updates" reports up-to-date vs newer-available (with a working link) — no binary download.
  • Version-compare core function has unit tests (older/newer/equal, v prefix, malformed input) — tested against a stubbed "latest" value, no live network in tests.
  • Offline / API-error path notifies gracefully (or stays silent for the auto check), never crashes.
  • Startup auto-check is throttled and can be turned off.
  • The private-repo reachability question above is resolved (or the issue is split so notify-UI lands behind a public source).

Filed by the supervisor (Cowork) session at AJ's request.

## Problem Users have no way to learn that a newer release exists — they'd have to manually visit the releases page. We ship versioned releases (v1.1.0 now) via the tag-triggered `release.yml`, but nothing tells an installed copy it's out of date. ## Proposed solution A lightweight **update check that notifies only — it does NOT download or replace the binary** (deliberate: self-replacing unsigned PyInstaller bundles is a Gatekeeper/file-lock headache we're avoiding). - Query the latest release, compare its version to the running `__version__`, and if newer, show a **non-blocking** notification (banner or dialog) with a link to the release/download page. - **Manual trigger:** a "Check for updates" button (in the About dialog). Reports "up to date" or "vX.Y.Z available". - **Optional auto trigger:** a quiet, throttled check on startup (e.g. at most once/day via QSettings timestamp), off-thread, that silently does nothing on failure/offline. Must be disableable in settings. ## Design notes / prerequisites - **Release source must be publicly reachable.** The repo is currently **private**, so the Gitea releases API (`GET /api/v1/repos/the_og/better-claude-config/releases/latest`) returns 401 to an anonymous, distributed app. Before this ships, either make the repo (or at least a releases/version manifest) public, or host a small public `version.json`. Do NOT embed a Gitea token in the distributed app. **Verify this first** — it blocks the feature. - **Version compare** belongs in `bcc_core.py` as a pure, unit-testable function: strip a leading `v`, compare numeric tuples (e.g. `(1,1,0)`), handle pre-release/garbage gracefully. Don't string-compare (`"1.10.0" < "1.9.0"` lexically is wrong). - **Network off the UI thread** (QThread), short timeout, fail quiet. No crash offline. - Reuse the `__version__` single source of truth from the About-page issue. ## Acceptance criteria - Manual "Check for updates" reports up-to-date vs newer-available (with a working link) — no binary download. - Version-compare core function has unit tests (older/newer/equal, `v` prefix, malformed input) — tested against a stubbed "latest" value, no live network in tests. - Offline / API-error path notifies gracefully (or stays silent for the auto check), never crashes. - Startup auto-check is throttled and can be turned off. - The private-repo reachability question above is resolved (or the issue is split so notify-UI lands behind a public source). _Filed by the supervisor (Cowork) session at AJ's request._
the_og added the P1 label 2026-07-04 16:36:16 -04:00
the_og commented 2026-07-04 16:39:15 -04:00
Author
Owner
Copy Link
Copy Source

Prerequisite resolved: the repo is now public (in prep for GitHub sync), so GET /api/v1/repos/the_og/better-claude-config/releases/latest is anonymously reachable. No public version.json or token embedding needed — the update check can hit the Gitea (and later GitHub) releases API directly. The "release source must be public" blocker above is cleared.

Prerequisite resolved: the repo is now **public** (in prep for GitHub sync), so `GET /api/v1/repos/the_og/better-claude-config/releases/latest` is anonymously reachable. No public `version.json` or token embedding needed — the update check can hit the Gitea (and later GitHub) releases API directly. The "release source must be public" blocker above is cleared.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
P0
P1
P2
blocked
Waiting on an external thing before it can move.
 decision
A decision record (D-007 style) — settled call, referenceable by number from any repo.
 needs-decision
Waiting on AJ's call.
 next
Current focus / next actionable item.
 status
The single pinned STATUS issue for this repo — live state, next action, open items, decisions needed.
No Label P1
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
the_og
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: the_og/better-claude-config#19
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?