Summary

Installing gogcli from a tagged module version with go install can produce a binary that reports a stale hardcoded development version instead of the installed tag.

Observed with v0.14.0:

go install github.com/steipete/gogcli/cmd/gog@v0.14.0
$(go env GOPATH)/bin/gog --version

Actual output:

0.13.0-dev

Expected output:

v0.14.0

Comparison With Release Artifact

The prebuilt GitHub release artifact for v0.14.0 reports the expected version:

curl -fsSL "https://github.com/steipete/gogcli/releases/download/v0.14.0/gogcli_0.14.0_linux_arm64.tar.gz" \
  | tar xz -C /usr/local/bin gog

gog --version

Output:

v0.14.0 (469f4b4 2026-04-28T09:39:03Z)

Likely Cause

The release artifacts are correct because GoReleaser injects version metadata through linker flags:

-X github.com/steipete/gogcli/internal/cmd.version={{ .Tag }}
-X github.com/steipete/gogcli/internal/cmd.commit={{ .ShortCommit }}
-X github.com/steipete/gogcli/internal/cmd.date={{ .Date }}

But go install github.com/steipete/gogcli/cmd/gog@v0.14.0 does not use those GoReleaser linker flags. It falls back to the hardcoded source value in internal/cmd/version.go, which currently looks like a stale release-specific dev version.

Impact

For environments that install with go install module@version, the binary appears to be a stale development build even when it was built from the requested tagged module version. This can confuse diagnostics, packaging verification, and support reports.

Related PR

I opened a fix here:

• fix: infer module version for source builds #545

That PR keeps GoReleaser-injected release metadata authoritative, but uses Go build metadata (runtime/debug.ReadBuildInfo) as the fallback for source/module builds. That means future installs like go install github.com/steipete/gogcli/cmd/gog@<tag> can report the installed module version instead of a stale hardcoded dev version.