sneak/mfer
1
0
Fork 0
Code Issues 2 Pull Requests 1 Actions Releases Wiki Activity

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

New Issue
Closed
opened 2026-08-09 03:43:38 +02:00 by clawbot · 2 comments
clawbot commented 2026-08-09 03:43:38 +02:00
Collaborator
Copy Link
Copy Source

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
clawbot commented 2026-10-13 13:00:04 +02:00
Author
Collaborator
Copy Link
Copy Source

Scope, 2026-10-13

Rewritten against the current tree; this replaces the definition of done above.

Today mfer/constants.go holds a hand-written Version = "0.1.0" and ReleaseDate = "2025-12-17". mfer version prints that number followed by main.Gitrev, the git describe --tags --always --dirty output that script/build and the Dockerfile stamp in; the banner prints v0.1.0 released 2025-12-17; main.Version is declared for -ldflags, but nothing sets or reads it. A tag on next would make mfer version print 0.1.0 beside the tag's name.

The version is the git tag and nothing else, so no version number is written in the tree to keep in step.

Definition of done

  • mfer version and mfer --version print mfer version <v>, where <v> is main.Gitrev as the build stamps it or, when that is empty (as after go install sneak.berlin/go/mfer/cmd/mfer@<tag>), the main module's version from runtime/debug.ReadBuildInfo.
  • The banner shows the same <v> and no release date.
  • Version and ReleaseDate leave mfer/constants.go; main.Version and the version plumbing in internal/cli that nothing reads go with them. A program using the library reads the module version from its own build information, as for any Go module.
  • Tests cover a stamped Gitrev and the build-information fallback.
  • The README says where the version comes from.
  • Nothing is tagged.
  • make check and script/cibuild pass.

Model: opus-5-5

## Scope, 2026-10-13 Rewritten against the current tree; this replaces the definition of done above. Today `mfer/constants.go` holds a hand-written `Version = "0.1.0"` and `ReleaseDate = "2025-12-17"`. `mfer version` prints that number followed by `main.Gitrev`, the `git describe --tags --always --dirty` output that `script/build` and the `Dockerfile` stamp in; the banner prints `v0.1.0 released 2025-12-17`; `main.Version` is declared for `-ldflags`, but nothing sets or reads it. A tag on `next` would make `mfer version` print `0.1.0` beside the tag's name. The version is the git tag and nothing else, so no version number is written in the tree to keep in step. ## Definition of done - `mfer version` and `mfer --version` print `mfer version <v>`, where `<v>` is `main.Gitrev` as the build stamps it or, when that is empty (as after `go install sneak.berlin/go/mfer/cmd/mfer@<tag>`), the main module's version from `runtime/debug.ReadBuildInfo`. - The banner shows the same `<v>` and no release date. - `Version` and `ReleaseDate` leave `mfer/constants.go`; `main.Version` and the version plumbing in `internal/cli` that nothing reads go with them. A program using the library reads the module version from its own build information, as for any Go module. - Tests cover a stamped `Gitrev` and the build-information fallback. - The README says where the version comes from. - Nothing is tagged. - `make check` and `script/cibuild` pass. Model: opus-5-5
clawbot commented 2026-10-13 19:15:32 +02:00
Author
Collaborator
Copy Link
Copy Source

Implemented in #204: the version now comes from the git tag alone, and mfer/constants.go no longer holds Version or ReleaseDate.

Model: opus-5-5

Implemented in https://git.eeqj.de/sneak/mfer/pulls/204: the version now comes from the git tag alone, and `mfer/constants.go` no longer holds `Version` or `ReleaseDate`. Model: opus-5-5
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
critical
Extremely important: data loss, a security hole, production down, or basic use impossible
 merge-ready
All checks pass, reviewed, rebased, ready for merge
 needs-checks
make check does not pass cleanly
 needs-rebase
PR has merge conflicts or is behind main
 needs-review
Code review not yet done
 needs-rework
Code review found issues to fix
No labels
Milestone
No items
No Milestone 1.0.0
Assignees
Clear assignees
clawbot sneak (Jeffrey Paul)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: sneak/mfer#80