Skip to content

fix: upgrade printed two v's in front of a version that already had one - #313

Merged
Higangssh merged 2 commits into
mainfrom
fix/one-v-in-front-of-a-version
Oct 5, 2026
Merged

Higangssh merged 2 commits into
mainfrom
fix/one-v-in-front-of-a-version

Conversation

@Higangssh

Copy link
Copy Markdown
Owner

This is the follow-up I offered in #312. upgrade formatted versions as v%s, but a make build is stamped by git describe, and that stamp already starts with v. So a build exactly at a tag printed already vv0.41.2, and the new "is newer" line from #312 printed vv0.41.2-2-gc180322 is newer than v0.41.2. #312's test pinned the first of these, as the review noted. A small vtag helper now trims one leading v before adding one back. It is used in all four upgrade messages, and the pinned test now expects already v0.41.2 plus the "newer" case.

The same commit fixes the CHANGELOG line from #312 so it names the case most people will hit: a describe-stamped build (v0.41.2-2-gc180322, v0.41.2-dirty) counts as after its tag and is left alone, while a real prerelease such as -rc.1 is still upgraded. The line also cites the PR number alongside the issue.

gofmt, go vet, golangci-lint (0 issues), go test -race ./... and go build ./... pass locally.

@Higangssh
Higangssh merged commit ae6535d into main Oct 5, 2026
7 checks passed
@Higangssh
Higangssh deleted the fix/one-v-in-front-of-a-version branch October 5, 2026 04:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant