Release mechanics for v1.0.0: version single-sourcing and tag #80

New Issue

clawbot · 2026-08-09T03:43:38+02:00

clawbot commented

2026-08-09 03:43:38 +02:00

Context

The final work unit for the milestone. Everything else in the 1.0.0
milestone must land first.

Current state:

mfer/constants.go:5 — Version = "0.1.0"
Makefile:9 — VERSION := 0.1.0
GOLDFLAGS injects -X main.Version=$(VERSION) into cmd/mfer

So the version is written down in at least two places that must be kept in
sync by hand, and a third value is injected at build time. There is nothing
preventing them from disagreeing, and nothing that checks.

The README commits to SemVer. The repo has no tags at all.

Definition of done

The version is single-sourced. One authoritative location; everything else
derives from it. make build, mfer --version, mfer version, and the
library constant all report the same string, and it is impossible for them
to drift.
A test asserts they agree, so drift fails the build rather than shipping.
mfer --version output is valid SemVer and matches the tag exactly.
mfer --version and mfer version produce identical output (see also
#64).
The version is bumped to 1.0.0.
docker build . succeeds and the built binary reports 1.0.0.
TODO.md and the README reflect that 1.0.0 is released.

Implementation requirements

Do not tag anything. Tagging is the owner's action. This issue ends with a
merged PR that leaves the repo ready to tag; the tag itself is sneak's.
Do not open this PR until every other issue in the 1.0.0 milestone is
closed. Verify the milestone is otherwise empty before starting, and say
so in the PR body.
Decide where the single source of truth lives and justify it. Injecting
via ldflags alone is insufficient — go install of the library does not
run the Makefile, so a consumer importing mfer as a library would see an
empty version. The Go constant is the more defensible source, with the
build verifying rather than supplying it.
ReleaseDate in mfer/constants.go needs the same treatment or an
explicit decision to drop it. A hand-maintained release date is another
thing that silently goes stale.
Confirm the module path question (#79) is resolved before this lands. A
1.0.0 tag on the wrong module path is not fixable without a 2.0.0.
Commit title must end with (closes #80).

## Context The final work unit for the milestone. Everything else in the `1.0.0` milestone must land first. Current state: - `mfer/constants.go:5` — `Version = "0.1.0"` - `Makefile:9` — `VERSION := 0.1.0` - `GOLDFLAGS` injects `-X main.Version=$(VERSION)` into `cmd/mfer` So the version is written down in at least two places that must be kept in sync by hand, and a third value is injected at build time. There is nothing preventing them from disagreeing, and nothing that checks. The README commits to SemVer. The repo has no tags at all. ## Definition of done - The version is single-sourced. One authoritative location; everything else derives from it. `make build`, `mfer --version`, `mfer version`, and the library constant all report the same string, and it is impossible for them to drift. - A test asserts they agree, so drift fails the build rather than shipping. - `mfer --version` output is valid SemVer and matches the tag exactly. - `mfer --version` and `mfer version` produce identical output (see also #64). - The version is bumped to `1.0.0`. - `docker build .` succeeds and the built binary reports `1.0.0`. - `TODO.md` and the README reflect that 1.0.0 is released. ## Implementation requirements - Do not tag anything. Tagging is the owner's action. This issue ends with a merged PR that leaves the repo ready to tag; the tag itself is `sneak`'s. - Do not open this PR until every other issue in the `1.0.0` milestone is closed. Verify the milestone is otherwise empty before starting, and say so in the PR body. - Decide where the single source of truth lives and justify it. Injecting via ldflags alone is insufficient — `go install` of the library does not run the Makefile, so a consumer importing `mfer` as a library would see an empty version. The Go constant is the more defensible source, with the build verifying rather than supplying it. - `ReleaseDate` in `mfer/constants.go` needs the same treatment or an explicit decision to drop it. A hand-maintained release date is another thing that silently goes stale. - Confirm the module path question (#79) is resolved before this lands. A 1.0.0 tag on the wrong module path is not fixable without a 2.0.0. - Commit title must end with ` (closes #80)`.

clawbot added this to the 1.0.0 milestone 2026-08-09 03:43:38 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: sneak/mfer#80