cmd/go: go mod download needs to support toolchain upgrades
#62054
Comments
bcmills
added
NeedsFix
|
@gopherbot, please backport to Go 1.21. This is a blocker for the Go module proxy to be able to deploy Go 1.21 releases with adequate pre-release testing. |
|
Backport issue(s) opened: #62055 (for 1.21). Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases. |
|
CC @golang/tools-team (since this involves the Go module mirror). Also CC @golang/release as FYI. |
|
Change https://go.dev/cl/537480 mentions this issue: |
|
Change https://go.dev/cl/539697 mentions this issue: |
|
Change https://go.dev/cl/540779 mentions this issue: |
…lready allow go.mod updates This fixes an inconsistency that was introduced in CL 537480 and noted in the review on CL 539697. In particular, 'go mod download' already updates the go.mod file when other kinds of updates are needed. (#45551 suggested that it should not do so, but that part of the change was not implemented yet; finishing that change is proposed as #64008.) Updates #62054. Change-Id: Ic659eb8538f4afdec0454737e982d42ef8957e56 Reviewed-on: https://go-review.googlesource.com/c/go/+/540779 Auto-Submit: Bryan Mills <bcmills@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Matloob <matloob@golang.org>
…lchains if called with explicit arguments Fixes #62055. Updates #62054. Change-Id: I4ea24070f7d9aa4964c2f215836602068058f718 (cherry picked from CL 540779 and CL 537480) Reviewed-on: https://go-review.googlesource.com/c/go/+/539697 Auto-Submit: Heschi Kreinick <heschi@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Matloob <matloob@golang.org>
and others
In the changes for
go mod downloadfor Go 1.21, we chose not to support toolchain upgrades duringgo mod download, because it was going to be fairly complicated to get right, and it wouldn't affect CI systems or users who run a plaingo mod downloadbefore running tests:https://cs.opensource.google/go/go/+/master:src/cmd/go/internal/modcmd/download.go;l=184-198;drc=8035de592fbc782d27eb78e914ca4e04ec991a3f
However, it turns out that it would be very useful for the Go module proxy itself — and probably other proxy implementations as well — to be able to
go mod downloadspecific module versions, branches,latest, and so on even if they require a newer toolchain than the one the proxy runs by default.This is especially important for minor releases, since modules may declare (say)
go 1.21.3as soon as Go 1.21.3 is released, which (in order to produce checksums for such a module) would require the proxy maintainer to either immediately deploy the new release for all modules (which greatly complicates pre-deployment testing), or detect failures and explicitly retry (which is exactly whatgo mod downloaditself would do).The text was updated successfully, but these errors were encountered: