You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We don't want the generated go.mod for the packages you import to specify anything, because you have no way to fix it if it's wrong.
On the other hand, if we're generating a new go.mod for a brand new module, and it imports a bunch of packages that have legacy lock files, we probably shouldn't synthesize a go.mod that requires versions older than what's in those lock files.
I think the root of the problem is the interaction between version tags, go.mod files, and pseudo-versions. Today, we do not treat a v2.0.0 tag as a semantic version unless it matches the import path: we resolve the tag to a commit and then store than commit as a pseudoversion, and treat all pseudoversions as older than all semantic versions. That sorts a pre-vgo v1.0.0 tag above a pre-vgo v2.0.0 tag.
Perhaps we should not treat a pre-vgo v1.0.0 as a valid semantic version either. Then, instead of picking github.com/dgrijalva/jwt-go v1.0.2 as the “latest” version, we would instead pick either v3.2.0 (the latest tag) or 06ea103 (the latest commit as of this comment), and existing packages would be more likely to build.
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes and the listed
vgo
commitWhat operating system and processor architecture are you using (
go env
)?What did you do?
This might be an intentional change as part of https://go-review.googlesource.com/120999, but I haven't had a chance to investigate further I'm afraid.
What did you expect to see?
A successful build.
What did you see instead?
Compare to the previous commit (06e664301cec279012e90c60689c5ad4e11fd3f1):
/cc @rsc @bcmills
The text was updated successfully, but these errors were encountered: