From d621611bddef769bf9672f9f3b4cb9b71bde881e Mon Sep 17 00:00:00 2001 From: mrambossek Date: Sun, 2 Aug 2026 13:54:42 +0200 Subject: [PATCH] docs: the v0.11.2 mystery was an unstamped-tag problem, not lost code Co-Authored-By: Claude Opus 5 --- docs/build-status.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/docs/build-status.md b/docs/build-status.md index 1a2b52a..c8891d3 100644 --- a/docs/build-status.md +++ b/docs/build-status.md @@ -1367,3 +1367,14 @@ Consequences until resolved: - The unpushed v0.10–v0.11 work needs to be found and pushed from whichever machine built it, or the deployed binary's provenance re-established some other way, before the release channel can be trusted again. + +**Resolved same day.** The binary itself settled it: `go version -m` on the deployed executable +shows `vcs.revision=d5b1bab` — a commit on this repo's master — built 2026-08-02 08:36 UTC with a +hand-stamped `-X main.Version=v0.11.2` and a dirty tree (`vcs.modified=true`, the then-uncommitted +schema doc). An earlier session stamped release numbers ahead of the tag line; no code was ever +missing. Current master is tagged and released as **server-v0.11.3** (signed), restoring a +monotonic, tag-backed lineage above the deployed number. The rule going forward: **the version a +binary is stamped with must be a pushed `server-v*` tag** — an ad-hoc stamp above the tag line +poisons `/releases/latest` for the string-comparing updater the moment anyone tags honestly again. +The stale `server-v0.9.2` release (same code lineage, wrong number, created during the confusion) +remains in Gitea but is harmless now that v0.11.3 outranks it as latest.