We regularly bump the minimum Go bootstrap version, once every year (see proposal #54265). One of the common ways that a bootstrap toolchain is provided to make.bash and related scripts is by having a "go" binary in PATH.
Every now and then, someone will have a fairly modern "go" in PATH, but one that no longer meets the minimum after it's been bumped. A quick and simple way to fix that is to rely on go.dev/doc/toolchain and fetch a sufficiently new toolchain yourself. Consider the sequence:
$ ./make.bash
error because go in PATH doesn't meet the minimum requirement
$ export GOROOT_BOOTSTRAP="$(GOTOOLCHAIN=go1.24.6 go env GOROOT)"
$ ./make.bash
okay now
Maybe it's worthwhile to reduce the friction here by having make.bash script and its Windows/Plan 9 counterparts be willing to do the above, provided the environment configuration permits it. That is, if the user has GOTOOLCHAIN=local or so, the script would print that it's not able to automatically download a newer version, and that's fine.
Whenever the version of go is already high enough, it'll continue to get used as is instead of downgrading. We don't want to prevent any toolchain ≥ Go 1.24.6 but < Go 1.x from being used. Even releases ≥ Go 1.x are likely to work and don't need to be prevented. This is about reaching the minimum in cases that have a clear path to do so.
I tried out two approaches in draft CLs go.dev/cl/696197 and go.dev/cl/696198. It's promising overall, but I'd like to do a bit more before sending them for review.
We regularly bump the minimum Go bootstrap version, once every year (see proposal #54265). One of the common ways that a bootstrap toolchain is provided to make.bash and related scripts is by having a "go" binary in PATH.
Every now and then, someone will have a fairly modern "go" in PATH, but one that no longer meets the minimum after it's been bumped. A quick and simple way to fix that is to rely on go.dev/doc/toolchain and fetch a sufficiently new toolchain yourself. Consider the sequence:
Maybe it's worthwhile to reduce the friction here by having make.bash script and its Windows/Plan 9 counterparts be willing to do the above, provided the environment configuration permits it. That is, if the user has
GOTOOLCHAIN=localor so, the script would print that it's not able to automatically download a newer version, and that's fine.Whenever the version of go is already high enough, it'll continue to get used as is instead of downgrading. We don't want to prevent any toolchain ≥ Go 1.24.6 but < Go 1.x from being used. Even releases ≥ Go 1.x are likely to work and don't need to be prevented. This is about reaching the minimum in cases that have a clear path to do so.
I tried out two approaches in draft CLs go.dev/cl/696197 and go.dev/cl/696198. It's promising overall, but I'd like to do a bit more before sending them for review.