go install @latest must install main's tip; retract v0.0.1; a go-installed binary must say which version it is #116

New Issue

2026-10-16T13:52:04+02:00

clawbot commented

2026-10-16 13:52:04 +02:00

The cause of sneak's three reports on #56 (diagnosis: #56 (comment)). His orders, on #56 (comment):

> 1. make go install ...@latest install the latest green commit, i.e. main's tip.

and on #116 (comment):

> rather than tagging release candidates, just release a 0.0.2 and an 0.0.3 and so on until a 1.0 is ready.

go install sneak.berlin/go/sfdupes@latest installs the newest release tag; Go skips v1.0.0-rc1 and v1.0.0-rc2 because they are release candidates. Until now that meant v0.0.1, the July build with no database, whose trees waits silently on stdin. A binary built by go install also reports its version as dev, so sfdupes --version cannot tell the user which build he has.

How the two orders fit together: releases are v0.0.N tags on main's tip. Each time main moves and its tip passes script/cibuild on a fresh clone, that tip is tagged with the next v0.0.N. @latest then installs main's tip. v0.0.2 tags the current tip of main (the same code as v1.0.0-rc2). The tag is not part of this PR.

Definition of done

README "Install": go install sneak.berlin/go/sfdupes@latest installs the newest release. Releases are v0.0.N tags on main's tip until 1.0, so @latest installs main's tip once it has passed the build. @main installs the tip before it is tagged. v0.0.1 is an early build without a database, retracted, and does not work as this README describes. Also: how to check an installed binary, with go version -m and with sfdupes --version as below. Any other README text about release candidate tags is updated to match.
go.mod gets a retract v0.0.1 directive with a short reason, so that once a release carrying it is the latest, Go warns anyone still on v0.0.1 and never picks it again.
sfdupes --version prints the version Go recorded in the binary when the linker set none: runtime/debug.ReadBuildInfo, the main module's version, a tag such as v0.0.2 or the pseudo-version of an @main build. A version set by the linker still wins. dev remains only when neither is known (Go records (devel)). README "Install" no longer says such a binary reports dev.
Tests: the version choice, through a function that takes the linker value and the build info (linker set; build info with a tag; (devel); no build info).
TODO.md Completed Steps entry in the same commit; script/cibuild green on a fresh clone.

Notes for the implementer

Package main (the repo's only package). The version choice belongs beside Version in main.go.
Small and plain; no new flags, no new dependencies.

Model: opus-5-5

The cause of sneak's three reports on https://git.eeqj.de/sneak/sfdupes/issues/56 (diagnosis: https://git.eeqj.de/sneak/sfdupes/issues/56#issuecomment-145003). His orders, on https://git.eeqj.de/sneak/sfdupes/issues/56#issuecomment-145021: > 1. make `go install ...@latest` install the latest green commit, i.e. main's tip. and on https://git.eeqj.de/sneak/sfdupes/issues/116#issuecomment-145022: > rather than tagging release candidates, just release a 0.0.2 and an 0.0.3 and so on until a 1.0 is ready. `go install sneak.berlin/go/sfdupes@latest` installs the newest release tag; Go skips `v1.0.0-rc1` and `v1.0.0-rc2` because they are release candidates. Until now that meant `v0.0.1`, the July build with no database, whose `trees` waits silently on stdin. A binary built by `go install` also reports its version as `dev`, so `sfdupes --version` cannot tell the user which build he has. How the two orders fit together: releases are `v0.0.N` tags on `main`'s tip. Each time `main` moves and its tip passes `script/cibuild` on a fresh clone, that tip is tagged with the next `v0.0.N`. `@latest` then installs `main`'s tip. `v0.0.2` tags the current tip of `main` (the same code as `v1.0.0-rc2`). The tag is not part of this PR. ## Definition of done - README "Install": `go install sneak.berlin/go/sfdupes@latest` installs the newest release. Releases are `v0.0.N` tags on `main`'s tip until 1.0, so `@latest` installs `main`'s tip once it has passed the build. `@main` installs the tip before it is tagged. `v0.0.1` is an early build without a database, retracted, and does not work as this README describes. Also: how to check an installed binary, with `go version -m` and with `sfdupes --version` as below. Any other README text about release candidate tags is updated to match. - `go.mod` gets a `retract v0.0.1` directive with a short reason, so that once a release carrying it is the latest, Go warns anyone still on `v0.0.1` and never picks it again. - `sfdupes --version` prints the version Go recorded in the binary when the linker set none: `runtime/debug.ReadBuildInfo`, the main module's version, a tag such as `v0.0.2` or the pseudo-version of an `@main` build. A version set by the linker still wins. `dev` remains only when neither is known (Go records `(devel)`). README "Install" no longer says such a binary reports `dev`. - Tests: the version choice, through a function that takes the linker value and the build info (linker set; build info with a tag; `(devel)`; no build info). - `TODO.md` Completed Steps entry in the same commit; `script/cibuild` green on a fresh clone. ## Notes for the implementer - Package `main` (the repo's only package). The version choice belongs beside `Version` in `main.go`. - Small and plain; no new flags, no new dependencies. Model: opus-5-5

clawbot added this to the 1.0.0 milestone 2026-10-16 13:52:04 +02:00

sneak commented

2026-10-16 13:57:06 +02:00

rather than tagging release candidates, just release a 0.0.2 and an 0.0.3 and so on until a 1.0 is ready.

clawbot changed title from ~~go install @latest installs the July prototype v0.0.1, and a go-installed binary cannot say which version it is~~ to go install @latest must install main's tip; retract v0.0.1; a go-installed binary must say which version it is

2026-10-16 14:03:07 +02:00

clawbot commented

2026-10-16 14:04:42 +02:00

v0.0.2 is tagged on main's tip (https://git.eeqj.de/sneak/sfdupes/src/tag/v0.0.2), the same code as v1.0.0-rc2. go install sneak.berlin/go/sfdupes@latest gives it once the Go module proxy refreshes its cached answer, which usually takes under an hour; @v0.0.2 works now.

Reading taken: every release tag goes on main's tip after that tip passes script/cibuild on a fresh clone, so @latest installs main's tip. The fixes now under way on next become v0.0.3 when you merge next into main (#110).

Model: opus-5-5

`v0.0.2` is tagged on `main`'s tip (https://git.eeqj.de/sneak/sfdupes/src/tag/v0.0.2), the same code as `v1.0.0-rc2`. `go install sneak.berlin/go/sfdupes@latest` gives it once the Go module proxy refreshes its cached answer, which usually takes under an hour; `@v0.0.2` works now. Reading taken: every release tag goes on `main`'s tip after that tip passes `script/cibuild` on a fresh clone, so `@latest` installs `main`'s tip. The fixes now under way on `next` become `v0.0.3` when you merge `next` into `main` (https://git.eeqj.de/sneak/sfdupes/pulls/110). Model: opus-5-5

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: sneak/sfdupes#116