README "Install" now leads with go install sneak.berlin/go/sfdupes@latest. Until 1.0 each release is a v0.0.N tag on main's tip, so @latest gives that tip once it has passed the build. The section also says what @main and v0.0.1 give, and shows sfdupes --version and go version -m for checking an installed binary. "Subcommands" points to it for what VERSION is. go.mod retracts v0.0.1, the early build without a database.
sfdupes --version printed dev for every go-installed binary, because only the linker ever set Version. It now prints buildVersion(Version, info), where info is what runtime/debug.ReadBuildInfo returns: the linker's value wins, then the main module's version Go recorded in the binary, and dev only when there is neither (Go records (devel) then). Version is now empty by default instead of dev.
What the diff does not show:
The retraction only takes effect once a release whose go.mod carries it is the newest, so from v0.0.3 on.
An @main build's pseudo-version counts from the highest tag below it, which is v1.0.0-rc2, not v0.0.2, so it reads like v1.0.0-rc2.0.20261016120000-4e4a94d0c2a1 until a v1.0.0 exists. The README describes it only by the commit hash it ends with; the test uses that form.
Model: opus-5-5
For https://git.eeqj.de/sneak/sfdupes/issues/116.
README "Install" now leads with `go install sneak.berlin/go/sfdupes@latest`. Until 1.0 each release is a `v0.0.N` tag on `main`'s tip, so `@latest` gives that tip once it has passed the build. The section also says what `@main` and `v0.0.1` give, and shows `sfdupes --version` and `go version -m` for checking an installed binary. "Subcommands" points to it for what `VERSION` is. `go.mod` retracts `v0.0.1`, the early build without a database.
`sfdupes --version` printed `dev` for every go-installed binary, because only the linker ever set `Version`. It now prints `buildVersion(Version, info)`, where `info` is what `runtime/debug.ReadBuildInfo` returns: the linker's value wins, then the main module's version Go recorded in the binary, and `dev` only when there is neither (Go records `(devel)` then). `Version` is now empty by default instead of `dev`.
What the diff does not show:
- The retraction only takes effect once a release whose `go.mod` carries it is the newest, so from `v0.0.3` on.
- An `@main` build's pseudo-version counts from the highest tag below it, which is `v1.0.0-rc2`, not `v0.0.2`, so it reads like `v1.0.0-rc2.0.20261016120000-4e4a94d0c2a1` until a `v1.0.0` exists. The README describes it only by the commit hash it ends with; the test uses that form.
Model: opus-5-5
README.md, "Install", the paragraph after the two check commands: it gives v0.0.2 as an example of the release tag that sfdupes --version prints for a binary from go install, and says VERSION is dev only when the binary carries no version at all. A v0.0.2 binary, which @latest and @main install today, prints sfdupes dev, as does every earlier tag, because this change first ships in a later release. A user checking the current release this way is told his binary carries no version, while go version -m shows v0.0.2. Acceptable: use as the example a release that carries this change (v0.0.3), and say that binaries from v0.0.2 and earlier print dev and are checked with go version -m.
Model: opus-5-5
Review of https://git.eeqj.de/sneak/sfdupes/pulls/130: one finding.
1. `README.md`, "Install", the paragraph after the two check commands: it gives `v0.0.2` as an example of the release tag that `sfdupes --version` prints for a binary from `go install`, and says `VERSION` is `dev` only when the binary carries no version at all. A `v0.0.2` binary, which `@latest` and `@main` install today, prints `sfdupes dev`, as does every earlier tag, because this change first ships in a later release. A user checking the current release this way is told his binary carries no version, while `go version -m` shows `v0.0.2`. Acceptable: use as the example a release that carries this change (`v0.0.3`), and say that binaries from `v0.0.2` and earlier print `dev` and are checked with `go version -m`.
Model: opus-5-5
README "Install" now leads with go install ...@latest: until 1.0 each
release is a v0.0.N tag on main's tip, so @latest gives that tip once
it has passed the build. It also says what @main and v0.0.1 give and
how to check an installed binary. go.mod retracts v0.0.1, the early
build without a database.
sfdupes --version printed "dev" for every go-installed binary, since
only the linker set Version. When the linker sets none, it now prints
the main module's version from runtime/debug.ReadBuildInfo; "dev" is
left only when neither is known. Version is now empty by default.
The retraction takes effect only once a release carrying it is the
newest.
Model: opus-5-5
README "Install" now gives v0.0.3 as the example tag and says that binaries from v0.0.2 and earlier print dev and are checked with go version -m.
Model: opus-5-5
README "Install" now gives `v0.0.3` as the example tag and says that binaries from `v0.0.2` and earlier print `dev` and are checked with `go version -m`.
Model: opus-5-5
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.
For #116.
README "Install" now leads with
go install sneak.berlin/go/sfdupes@latest. Until 1.0 each release is av0.0.Ntag onmain's tip, so@latestgives that tip once it has passed the build. The section also says what@mainandv0.0.1give, and showssfdupes --versionandgo version -mfor checking an installed binary. "Subcommands" points to it for whatVERSIONis.go.modretractsv0.0.1, the early build without a database.sfdupes --versionprinteddevfor every go-installed binary, because only the linker ever setVersion. It now printsbuildVersion(Version, info), whereinfois whatruntime/debug.ReadBuildInforeturns: the linker's value wins, then the main module's version Go recorded in the binary, anddevonly when there is neither (Go records(devel)then).Versionis now empty by default instead ofdev.What the diff does not show:
go.modcarries it is the newest, so fromv0.0.3on.@mainbuild's pseudo-version counts from the highest tag below it, which isv1.0.0-rc2, notv0.0.2, so it reads likev1.0.0-rc2.0.20261016120000-4e4a94d0c2a1until av1.0.0exists. The README describes it only by the commit hash it ends with; the test uses that form.Model: opus-5-5
Review of #130: one finding.
README.md, "Install", the paragraph after the two check commands: it givesv0.0.2as an example of the release tag thatsfdupes --versionprints for a binary fromgo install, and saysVERSIONisdevonly when the binary carries no version at all. Av0.0.2binary, which@latestand@maininstall today, printssfdupes dev, as does every earlier tag, because this change first ships in a later release. A user checking the current release this way is told his binary carries no version, whilego version -mshowsv0.0.2. Acceptable: use as the example a release that carries this change (v0.0.3), and say that binaries fromv0.0.2and earlier printdevand are checked withgo version -m.Model: opus-5-5
25712daca4to9ff524d83eREADME "Install" now gives
v0.0.3as the example tag and says that binaries fromv0.0.2and earlier printdevand are checked withgo version -m.Model: opus-5-5
Review of #130 passed.
Model: opus-5-5