-
Notifications
You must be signed in to change notification settings - Fork 17.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cmd/go: reject vN.*.*+incompatible as a version if vN/go.mod exists #36438
Comments
I've marked this issue as |
So with one of these versions, users would not be able to import anything in I'd lean toward fixing this, but we should understand how many module versions this will break. Hopefully a very small number. |
Correct, a user could not import packages from The
|
This issue is currently in the 1.15 milestone. Should we roll it forward? |
Done. |
Is there anything to do here for 1.17? Thanks. |
I still think we should add a diagnostic for this, but to my knowledge nobody is planning to do that for a specific release — so moving to Backlog. |
A partial fix for this falls out naturally from #51324: if we don't implicitly add However, at this point I do plan to retain compatibility for the |
Change https://go.dev/cl/387675 mentions this issue: |
… a subdirectory for that version Previous versions of the 'go' command would reject a pseudo-version passed to 'go get' if that pseudo-version had a mismatched major version and lacked a "+incompatible" suffix. However, they would erroneously accept a version *with* a "+incompatible" suffix even if the repo contained a vN/go.mod file for the same major version, and would generate a "+incompatible" pseudo-version or version if the user requested a tag, branch, or commit hash. This change uniformly rejects "vN.…" without "+incompatible", and also avoids resolving to "vN.…+incompatible", when vN/go.mod exists. To maintain compatibility with existing go.mod files, it still accepts "vN.…+incompatible" if the version is requested explicitly as such and the repo root lacks a go.mod file. Fixes #51324 Updates #36438 Change-Id: I2b16150c73fc2abe4d0a1cd34cb1600635db7139 Reviewed-on: https://go-review.googlesource.com/c/go/+/387675 Trust: Bryan Mills <bcmills@google.com> Reviewed-by: Michael Matloob <matloob@golang.org>
Change https://go.dev/cl/387921 mentions this issue: |
Change https://go.dev/cl/387922 mentions this issue: |
Change https://go.dev/cl/387923 mentions this issue: |
… a go.mod file exists in a subdirectory for that version Previous versions of the 'go' command would reject a pseudo-version passed to 'go get' if that pseudo-version had a mismatched major version and lacked a "+incompatible" suffix. However, they would erroneously accept a version *with* a "+incompatible" suffix even if the repo contained a vN/go.mod file for the same major version, and would generate a "+incompatible" pseudo-version or version if the user requested a tag, branch, or commit hash. This change uniformly rejects "vN.…" without "+incompatible", and also avoids resolving to "vN.…+incompatible", when vN/go.mod exists. To maintain compatibility with existing go.mod files, it still accepts "vN.…+incompatible" if the version is requested explicitly as such and the repo root lacks a go.mod file. Fixes #51332 Updates #51324 Updates #36438 Change-Id: I2b16150c73fc2abe4d0a1cd34cb1600635db7139 Reviewed-on: https://go-review.googlesource.com/c/go/+/387675 Trust: Bryan Mills <bcmills@google.com> Reviewed-by: Michael Matloob <matloob@golang.org> (cherry picked from commit 5a9fc94) Reviewed-on: https://go-review.googlesource.com/c/go/+/387922 Run-TryBot: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
… a go.mod file exists in a subdirectory for that version Previous versions of the 'go' command would reject a pseudo-version passed to 'go get' if that pseudo-version had a mismatched major version and lacked a "+incompatible" suffix. However, they would erroneously accept a version *with* a "+incompatible" suffix even if the repo contained a vN/go.mod file for the same major version, and would generate a "+incompatible" pseudo-version or version if the user requested a tag, branch, or commit hash. This change uniformly rejects "vN.…" without "+incompatible", and also avoids resolving to "vN.…+incompatible", when vN/go.mod exists. To maintain compatibility with existing go.mod files, it still accepts "vN.…+incompatible" if the version is requested explicitly as such and the repo root lacks a go.mod file. Fixes #51331 Updates #51324 Updates #36438 Change-Id: I2b16150c73fc2abe4d0a1cd34cb1600635db7139 Reviewed-on: https://go-review.googlesource.com/c/go/+/387675 Trust: Bryan Mills <bcmills@google.com> Reviewed-by: Michael Matloob <matloob@golang.org> (cherry picked from commit 5a9fc94) Reviewed-on: https://go-review.googlesource.com/c/go/+/387923 Run-TryBot: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
(From a golang-nuts thread.)
What version of Go are you using (
go version
)?What did you do?
Run
go get
in module mode, requesting an incompatible major version of a module that has ago.mod
file corresponding to that major version using the “major subdirectory” layout, but lacks ago.mod
file altogether at the repo root.What did you expect to see?
An error message indicating that
v2.0.3+incompatible
is not valid forgithub.com/nicksnyder/go-i18n
because the repository contains av2/go.mod
.(See #32695 and #34165.)
What did you see instead?
CC @matloob @jayconrod @thepudds @heschik @hyangah @katiehockman
The text was updated successfully, but these errors were encountered: