pkg.go.dev and semver tags with build metadata

[Tim Hockin]

Hi all, this was surprising to me:

This works:

https://pkg.go.dev/github.com/go-logr/za...@v1.0.0

This doesn't:

https://pkg.go.dev/github.com/go-logr/za...@v1.0.0+1

Both are valid tags and both are valid semver ("Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version").

Is this supposed to work?  Or does that tag run afoul of some go modules rule (I looked but found nothing canonical) ?

Thanks!

Tim

[Jay Conrod]

The go command removes build metadata as part of version canonicalization. +incompatible is the only metadata that may remain, but that can't appear in the vcs tag itself. Versions says a bit about this in the last paragraph (but it's arguably not clear enough on this point).

It looks like `go get -d github.com/go-logr/za...@v1.0.0+1` works, but will give you v1.0.1-0.20210809170106-a3325063a237, the psuedo-version for that commit.

pkg.go.dev gives a 404 with a link to the same page. I don't think that's correct. I'd expect it to link to v1.0.1-0.20210809170106-a3325063a237 instead.

The rationale for this is that semver requires that build metadata must be ignored when determining precedence. In the module graph, if you have a module D indirectly required at both v1.0.0+a and v1.0.0+b, those versions must compare equal, and there would be no way to pick which one to use.

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/8842fae9-eec3-4828-8906-f2be31a163fan%40googlegroups.com.

[juli...@google.com]

I filed https://github.com/golang/go/issues/47757.

[Tim Hockin]

On Tue, Aug 17, 2021 at 11:21 AM Jay Conrod <jayc...@google.com> wrote:

The go command removes build metadata as part of version canonicalization. +incompatible is the only metadata that may remain, but that can't appear in the vcs tag itself. Versions says a bit about this in the last paragraph (but it's arguably not clear enough on this point).

It looks like `go get -d github.com/go-logr/za...@v1.0.0+1` works, but will give you v1.0.1-0.20210809170106-a3325063a237, the psuedo-version for that commit.

pkg.go.dev gives a 404 with a link to the same page. I don't think that's correct. I'd expect it to link to v1.0.1-0.20210809170106-a3325063a237 instead.

The rationale for this is that semver requires that build metadata must be ignored when determining precedence. In the module graph, if you have a module D indirectly required at both v1.0.0+a and v1.0.0+b, those versions must compare equal, and there would be no way to pick which one to use.

I see.  So the use of `+1` here is actually inappropriate - it came with a modules dep change.  I was trying to represent that this CODE didn't change but the dep did.  From a modules POV that's wrong.  The module changed.

Thanks.  I'll avoid this in the future.