turbo-editors/turbo-go · 2026-09-01-build-time-version-check.md

⑂ main

2026-09-01-build-time-version-check.md · 32 lines · 1.7 KBmarkdown    Blame HistoryRaw
   1# Handoff — 2026-09-01 — the build checks the version it stamped
5Done. `scripts/check-version.sh` runs the freshly built binary and compares what it reports against what the build meant to stamp. It is called from three places:
7| Caller | When | On failure |
8| --- | --- | --- |
9| `make build` | after linking | the build fails |
10| `scripts/install.sh` | on the staged binary, before the rename | nothing is installed; the binary already there is untouched |
11| `03-build-releases.sh` | on the one staged asset this machine can run | the release build stops |
13Eight tests in `version_check_test.go`; three of them falsified. Suite green, quality gate PASS 0/0/0. Documented in `docs/{en,fr}/reference/versioning.md`.
15## In flight
19## Next steps
211. Nothing specific — it ships with the rest of the branch.
23## Open questions / blockers
27## Watch out for
29- **The comparison must stay an equality.** `0.2.0` is a substring of `10.2.0` and of a commit hash that happens to contain it. The release script used `grep -qF` and would have accepted either; there is a test named for exactly that case.
30- **The check goes before the install, not after.** A binary that cannot name its own version must never replace one that can, and there is a test asserting the ordering in `install.sh`.
31- **The failure this catches is silent.** `-X` naming a symbol that does not exist is not a link error. If you rename anything in turbo-core's `version` package, the Makefile's `-X` paths go stale and *nothing* says so except this check.
32- **An unstamped build is legitimate.** Installing from a tarball has no git checkout to describe, so the check is called with no expected version and only refuses `unknown`.

📦 Turbo Go 3d7798b k33g 11h ago	1	# Handoff — 2026-09-01 — the build checks the version it stamped
	2
	3	## State
	4
	5	Done. `scripts/check-version.sh` runs the freshly built binary and compares what it reports against what the build meant to stamp. It is called from three places:
	6
	7	\| Caller \| When \| On failure \|
	8	\| --- \| --- \| --- \|
	9	\| `make build` \| after linking \| the build fails \|
	10	\| `scripts/install.sh` \| on the staged binary, before the rename \| nothing is installed; the binary already there is untouched \|
	11	\| `03-build-releases.sh` \| on the one staged asset this machine can run \| the release build stops \|
	12
	13	Eight tests in `version_check_test.go`; three of them falsified. Suite green, quality gate PASS 0/0/0. Documented in `docs/{en,fr}/reference/versioning.md`.
	14
	15	## In flight
	16
	17	Nothing.
	18
	19	## Next steps
	20
	21	1. Nothing specific — it ships with the rest of the branch.
	22
	23	## Open questions / blockers
	24
	25	- None.
	26
	27	## Watch out for
	28
	29	- The comparison must stay an equality. `0.2.0` is a substring of `10.2.0` and of a commit hash that happens to contain it. The release script used `grep -qF` and would have accepted either; there is a test named for exactly that case.
	30	- The check goes before the install, not after. A binary that cannot name its own version must never replace one that can, and there is a test asserting the ordering in `install.sh`.
	31	- The failure this catches is silent. `-X` naming a symbol that does not exist is not a link error. If you rename anything in turbo-core's `version` package, the Makefile's `-X` paths go stale and nothing says so except this check.
	32	- An unstamped build is legitimate. Installing from a tarball has no git checkout to describe, so the check is called with no expected version and only refuses `unknown`.