Handoff — 2026-09-01 — the build checks the version it stamped

State

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:

Caller	When	On failure
`make build`	after linking	the build fails
`scripts/install.sh`	on the staged binary, before the rename	nothing is installed; the binary already there is untouched
`03-build-releases.sh`	on the one staged asset this machine can run	the release build stops

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.

In flight

Nothing.

Next steps

Nothing specific — it ships with the rest of the branch.

Open questions / blockers

None.

Watch out for

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.
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.
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.
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.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32


# Handoff — 2026-09-01 — the build checks the version it stamped

## State

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:

| Caller | When | On failure |
| --- | --- | --- |
| `make build` | after linking | the build fails |
| `scripts/install.sh` | on the staged binary, before the rename | nothing is installed; the binary already there is untouched |
| `03-build-releases.sh` | on the one staged asset this machine can run | the release build stops |

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`.

## In flight

Nothing.

## Next steps

1. Nothing specific — it ships with the rest of the branch.

## Open questions / blockers

- None.

## Watch out for

- **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.
- **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`.
- **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.
- **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`.