fix: infer module version for source builds#545
Closed
joshavant wants to merge 1 commit intoopenclaw:mainfrom
Closed
fix: infer module version for source builds#545joshavant wants to merge 1 commit intoopenclaw:mainfrom
joshavant wants to merge 1 commit intoopenclaw:mainfrom
Conversation
Collaborator
|
Thanks for the PR. This fix is already on Verified current |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This makes version reporting use Go build metadata as a fallback when release metadata has not been injected by linker flags.
Release builds still work the same way: GoReleaser injects
version,commit, anddatewith-ldflags, and those injected values remain authoritative. For source/module builds without those linker flags,gognow falls back todebug.ReadBuildInfo()and reports the main module version when Go provides one.Why
go install github.com/steipete/gogcli/cmd/gog@v0.14.0does not run through GoReleaser, so it does not receive the release workflow's-ldflags. Before this change, those builds fell back to the hardcoded source value (0.13.0-dev), which made a binary built from a newer tag look like an older development build.That is misleading for diagnostics, support reports, and packaging verification.
Why This Change
This keeps the release workflow and GoReleaser config unchanged while improving source-build behavior:
v0.14.0 (commit date).go install module@versioncan report the module version from Go's build info.devwhen no useful module version is available.Verification
go test ./internal/cmdgo test ./cmd/goggo build -o /tmp/gog-dev ./cmd/gog && /tmp/gog-dev --versionprints the local module/VCS-derived build versiongo build -ldflags \"-X github.com/steipete/gogcli/internal/cmd.version=v9.9.9 -X github.com/steipete/gogcli/internal/cmd.commit=abc123 -X github.com/steipete/gogcli/internal/cmd.date=2026-05-01T00:00:00Z\" -o /tmp/gog-release ./cmd/gog && /tmp/gog-release --versionprintsv9.9.9 (abc123 2026-05-01T00:00:00Z)Related issue: #544