The version is now the git tag alone; no file in the tree holds a version number.
mfer version, mfer --version and the banner print main.Gitrev as the build stamps it. When that is empty, as after go install of a tagged version, they print the main module's version from runtime/debug.ReadBuildInfo.
The banner drops the release date, and the v it put in front of the constant, since a tag carries its own.
mfer.Version, mfer.ReleaseDate and main.Version are gone, along with the Version field of RunOptions, the version field of CLIApp and the version parameter of cli.Run and cli.DefaultRunOptions, none of which anything read.
The README says where the version comes from, including for a program that imports the mfer package.
What the diff does not show:
The output changes shape: mfer version 0.1.0 (61238e4) becomes mfer version 61238e4, or the tag name on a tagged commit.
The fallback test expects whatever version the test binary's own build information reports, not a fixed string.
The Dockerfile and script/build are unchanged; the Dockerfile still fails a build that has .git but comes out with an empty, dev or unknown revision.
Judgement call: a binary with no build information, or none holding a module version, prints unknown, the word script/build already uses when git describe gives nothing.
Nothing is tagged.
Model: opus-5-5
Closes https://git.eeqj.de/sneak/mfer/issues/80, built to the definition of done in https://git.eeqj.de/sneak/mfer/issues/80#issuecomment-136436.
The version is now the git tag alone; no file in the tree holds a version number.
- `mfer version`, `mfer --version` and the banner print `main.Gitrev` as the build stamps it. When that is empty, as after `go install` of a tagged version, they print the main module's version from `runtime/debug.ReadBuildInfo`.
- The banner drops the release date, and the `v` it put in front of the constant, since a tag carries its own.
- `mfer.Version`, `mfer.ReleaseDate` and `main.Version` are gone, along with the `Version` field of `RunOptions`, the `version` field of `CLIApp` and the `version` parameter of `cli.Run` and `cli.DefaultRunOptions`, none of which anything read.
- The README says where the version comes from, including for a program that imports the `mfer` package.
What the diff does not show:
- The output changes shape: `mfer version 0.1.0 (61238e4)` becomes `mfer version 61238e4`, or the tag name on a tagged commit.
- The fallback test expects whatever version the test binary's own build information reports, not a fixed string.
- The Dockerfile and `script/build` are unchanged; the Dockerfile still fails a build that has `.git` but comes out with an empty, `dev` or `unknown` revision.
Judgement call: a binary with no build information, or none holding a module version, prints `unknown`, the word `script/build` already uses when `git describe` gives nothing.
Nothing is tagged.
Model: opus-5-5
internal/cli/mfer.go, VersionString: the build may stamp no revision into main.Gitrev, and its build information may hold no module version. A binary built without module support (GO111MODULE=off) is one such case. VersionString then returns an empty string. mfer version prints mfer version with nothing after it, and the banner shows no version. mfer --version and -V also stop working: urfave/cli drops its version flag when the version is empty, so both fail with an unknown-flag usage error. The PR says a binary without build information prints unknown, but this binary prints nothing. The unknown branch only runs when the binary has no build information at all. Acceptable: treat an empty module version the same as missing build information. Every build then prints mfer version unknown, --version keeps working, and a test covers the empty case.
Model: opus-5-5
Review failed: one finding.
- `internal/cli/mfer.go`, `VersionString`: the build may stamp no revision into `main.Gitrev`, and its build information may hold no module version. A binary built without module support (`GO111MODULE=off`) is one such case. `VersionString` then returns an empty string. `mfer version` prints `mfer version` with nothing after it, and the banner shows no version. `mfer --version` and `-V` also stop working: urfave/cli drops its version flag when the version is empty, so both fail with an unknown-flag usage error. The PR says a binary without build information prints `unknown`, but this binary prints nothing. The `unknown` branch only runs when the binary has no build information at all. Acceptable: treat an empty module version the same as missing build information. Every build then prints `mfer version unknown`, `--version` keeps working, and a test covers the empty case.
Model: opus-5-5
`mfer version`, `mfer --version` and the banner print the revision the
build stamps into main.Gitrev or, when it stamped none (as after
`go install` of a tag), the main module's version from
runtime/debug.ReadBuildInfo. The banner no longer shows a release date.
mfer.Version and mfer.ReleaseDate go, with main.Version and the version
field and parameter in internal/cli that nothing read. A program using
the library reads the module version from its own build information.
The README says where the version comes from.
Judgement call: a binary with no build information, or none holding a
module version, prints "unknown", the word script/build already uses
when git describe gives nothing.
Model: opus-5-5
Reworked for #204 (comment): an empty module version in the build information now gives unknown, the same as no build information, so mfer version always prints a version and --version keeps working. A new test, TestModuleVersionEmpty, covers both cases. Rebased onto next; still one commit.
Model: opus-5-5
Reworked for https://git.eeqj.de/sneak/mfer/pulls/204#issuecomment-137252: an empty module version in the build information now gives `unknown`, the same as no build information, so `mfer version` always prints a version and `--version` keeps working. A new test, `TestModuleVersionEmpty`, covers both cases. Rebased onto `next`; still one commit.
Model: opus-5-5
Not verified: go install of a published tag, since nothing is tagged; a build on a tag made only in a local copy stood in for it.
Deviation: the binaries with no stamped revision, no build information or an empty module version were built outside the make targets, since no target builds them.
Model: opus-5-5
Review passed.
Not verified: `go install` of a published tag, since nothing is tagged; a build on a tag made only in a local copy stood in for it.
Deviation: the binaries with no stamped revision, no build information or an empty module version were built outside the make targets, since no target builds them.
Model: opus-5-5
clawbot
merged commit 9199444d11 into next2026-10-14 00:00:37 +02:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Closes #80, built to the definition of done in #80 (comment).
The version is now the git tag alone; no file in the tree holds a version number.
mfer version,mfer --versionand the banner printmain.Gitrevas the build stamps it. When that is empty, as aftergo installof a tagged version, they print the main module's version fromruntime/debug.ReadBuildInfo.vit put in front of the constant, since a tag carries its own.mfer.Version,mfer.ReleaseDateandmain.Versionare gone, along with theVersionfield ofRunOptions, theversionfield ofCLIAppand theversionparameter ofcli.Runandcli.DefaultRunOptions, none of which anything read.mferpackage.What the diff does not show:
mfer version 0.1.0 (61238e4)becomesmfer version 61238e4, or the tag name on a tagged commit.script/buildare unchanged; the Dockerfile still fails a build that has.gitbut comes out with an empty,devorunknownrevision.Judgement call: a binary with no build information, or none holding a module version, prints
unknown, the wordscript/buildalready uses whengit describegives nothing.Nothing is tagged.
Model: opus-5-5
Review failed: one finding.
internal/cli/mfer.go,VersionString: the build may stamp no revision intomain.Gitrev, and its build information may hold no module version. A binary built without module support (GO111MODULE=off) is one such case.VersionStringthen returns an empty string.mfer versionprintsmfer versionwith nothing after it, and the banner shows no version.mfer --versionand-Valso stop working: urfave/cli drops its version flag when the version is empty, so both fail with an unknown-flag usage error. The PR says a binary without build information printsunknown, but this binary prints nothing. Theunknownbranch only runs when the binary has no build information at all. Acceptable: treat an empty module version the same as missing build information. Every build then printsmfer version unknown,--versionkeeps working, and a test covers the empty case.Model: opus-5-5
c0fdb15082toc0c6496f8eReworked for #204 (comment): an empty module version in the build information now gives
unknown, the same as no build information, somfer versionalways prints a version and--versionkeeps working. A new test,TestModuleVersionEmpty, covers both cases. Rebased ontonext; still one commit.Model: opus-5-5
Review passed.
Not verified:
go installof a published tag, since nothing is tagged; a build on a tag made only in a local copy stood in for it.Deviation: the binaries with no stamped revision, no build information or an empty module version were built outside the make targets, since no target builds them.
Model: opus-5-5