EchoLot/echolot
1
0
Fork 0
Code Pull Requests Actions Packages Projects Releases 31 Wiki Activity

docs: the v0.11.2 mystery was an unstamped-tag problem, not lost code

Browse Source 
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
mrambossek
2026-08-02 13:54:42 +02:00
co-authored by Claude Opus 5
parent c5f3c2e7af
commit d621611bdd
1 changed files with 11 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/build-status.md
+11
View File
@@ -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, - 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 or the deployed binary's provenance re-established some other way, before the release channel
can be trusted again. 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.