release: publish the tarball on a tag, and stop a tag meaning nothing

[sajonaro]

A tag produced an image and nothing else. make release built a portable tarball on somebody's laptop, where it stayed — this repository has no GitHub releases at all, and the tarball is the artifact with the largest surface and the least coverage: a build profile nothing else uses (static), a stdlib copy by a path only it knows, an install.sh no suite runs.

The version is not in the tag

It is (version …) in dune-project, and every artifact reads it from there — the tarball's name, writ --version, the image tag, the opam package. The tag only fires the workflow. So tagging v0.2.0 without bumping dune-project publishes an image tagged 0.1.0, a tarball named 0.1.0 and a binary that reports 0.1.0, under a release called v0.2.0. That is not a hypothetical — it is the default outcome of tagging, because the bump is a separate act nothing forced.

scripts/check-release-tag.sh	the tag's shape, its agreement with dune-project, and that it goes forward. Run by release.yml and image-publish.yml before either builds, and by hand before pushing a tag.
scripts/check-versions.sh	the three files that keep a hand-written copy of the version because nothing substitutes into them: writ.opam, the Claude plugin's manifest, and the image tag that plugin pulls — the one whose staleness is invisible, since an old image runs perfectly and just answers as an older writ.
scripts/test-check-release-tag.sh	the rule itself, against cases rather than against whatever this checkout's tags happen to be.

What now ships on a tag

release.yml checks the tag, builds a tarball per architecture, and attaches both plus their checksums to a GitHub release whose body opens with the tag's own annotation — the line someone deciding whether to upgrade actually reads — followed by the three install routes.

tarball-build.yml is that build, once, as a called workflow: the shape image-build.yml already established here, for the same reason. ci.yml runs it on every pull request and release.yml runs it on a tag, so the thing checked on the way in is the thing that ships. It builds on an x86_64 and an aarch64 runner natively, then unpacks the tarball, installs it into an empty prefix and uses it from a third directory — writ --version against dune-project, a model, a .rules file, and all three binaries including writ-lsp, which the image does not carry and nothing else checks. It also asserts the link came out static, which is the only place README's "no libc version floor" claim can fail: a dynamically linked binary works perfectly on the machine that built it.

And a CI workflow, which did not exist

Nothing in CI ran make test — the only workflows were the image ones and the CLA bot, so a pull request could turn every suite red behind a green docker build. A release is cut from a tag on main, and a tag is only as good as what main was in. ci.yml runs build, suites, ocamlformat, the version checks, and a check that writ.opam still matches the file it is generated from.

Not in this PR

No tag is cut and none is touched. dune-project still says 0.1.0; README now documents the three steps that make a release.

🤖 Generated with Claude Code