Make preview versions monotonic and distinguishable from production #37

Merged

jknapp merged 3 commits from fix/preview-version-numbering into main 2026-08-27 17:41:38 +00:00

Conversation 0 Commits 3 Files Changed 5

+303 -95

3 Commits

Author	SHA1	Message	Date
shadow-testandClaude Sonnet 5	049232099b	Dedupe the preview-build predicate, fix two comment inaccuracies ... Final review pass gave this a clean bill of health overall but named three small things: - get_app_version() and check_for_updates() each read option_env!("TRIPLE_C_BUILD_SUFFIX") independently with slightly different idioms — if one were ever edited alone, the About panel and the update check could silently disagree about whether this is a preview build. Extracted preview_build_suffix() as the single place that reads and classifies it. - pick_update's doc comment described the unparseable-tag case as a `-preview.<sha>` suffix; the actual tag build-app-preview.yml creates is `preview-<sha>` (no version, no dot) — already correct in the neighboring GitHubRelease::prerelease comment, just not here. - That same prerelease comment claimed defence against a preview release leaking through backfill-releases.yml, but a preview's tag already fails semver parsing on its own — this field's actual job is the case parsing can't catch: a normally-tagged release someone flags prerelease on Gitea (a hotfix candidate, an RC) that a backfill would otherwise mirror as-is. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FGjXq6fqtAFHdbhk4f3PfZ	2026-08-27 10:34:56 -07:00
shadow-testandClaude Sonnet 5	945883bb9d	Actually offer a preview the release it precedes, and fix two more gaps ... An Opus review of the previous commit found its headline claim didn't hold: a preview and the release it precedes compute to the identical numeric version by construction, but check_for_updates compared with a strict `>` against the bare CARGO_PKG_VERSION (never the suffixed display string), so `(0,4,13) > (0,4,13)` is false and the release was never offered. Plain semver ordering doesn't make a `-preview.<sha>` suffix sort below the same numeric release on its own here, since the comparison never sees the suffix at all. pick_update now takes is_preview_build, derived from whether TRIPLE_C_BUILD_SUFFIX was baked in, and relaxes that one comparison to `>=` — so "a release exists at my own number" reads as an update. A production build still requires strictly newer. Also: ported build-app.yml's `git tag --points-at HEAD` guard into the preview version computation. Without it, workflow_dispatch (which this workflow allows on main, not just PR builds) run on a commit a release was already cut from would compute one past that release — reintroducing "preview outranks production" through the manual-dispatch door. And corrected two comments that claimed the prerelease filter was currently a no-op: backfill-releases.yml mirrors every Gitea release to GitHub unfiltered, prerelease flag included, so it's real defence-in-depth against a dispatched backfill leaking a preview release, not a no-op. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FGjXq6fqtAFHdbhk4f3PfZ	2026-08-27 10:24:24 -07:00
shadow-testandClaude Sonnet 5	b71e15c2c0	Make preview versions monotonic and distinguishable from production ... build-app-preview.yml computed its patch number as `git rev-list --count <latest tag>..HEAD` — the exact formula build-app.yml itself documents as broken and replaced (#26): a distance from whichever tag sorts highest, not a counter, so it resets to zero on every release and previews went backwards (0.4.62 -> 0.4.0) the moment one landed. Ported the same "one past the highest patch already used" computation build-app.yml uses for real releases, reading the same tags (including -mac/-win suffixes), so a preview built right before a release now computes the exact number that release is about to take — semver already orders `0.4.12-preview.<sha> < 0.4.12`, so a preview user is offered the release the moment it ships instead of being silently pinned forever. The installed preview's reported version was also indistinguishable from production: the bundle's own version field strips the `-preview.<sha>` suffix before touching tauri.conf.json/Cargo.toml/package.json, since the Windows MSI's ProductVersion has no room for one. Rather than risk that (unverifiable without an actual Windows build), preview builds now bake the suffix into the binary separately via a TRIPLE_C_BUILD_SUFFIX build-time env var, and get_app_version() appends it when present — a production build sets nothing, so this is a no-op there. Also: added `prerelease` to `GitHubRelease` and filter on it in check_for_updates (currently a no-op against real data — nothing mirrored to GitHub is ever prerelease:true — but the updater is no longer structurally incapable of enforcing a channel split if one is ever made explicit). And deleted sync-release.yml: workflow_dispatch-only, reading gitea.event.release.* fields a manual dispatch never populates, so it could never have actually run; build-app.yml's inline mirror already does the same job. Refactored check_for_updates' filtering into a pure, testable pick_update helper (this file had no tests before), and added tests for it and the new get_app_version suffix handling. Fixes #32. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FGjXq6fqtAFHdbhk4f3PfZ	2026-08-27 10:11:35 -07:00