-
Notifications
You must be signed in to change notification settings - Fork 17.8k
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
proposal: cmd/go: GOTOOLCHAIN=mod to use exact version of toolchain directive #69956
Comments
This comment was marked as off-topic.
This comment was marked as off-topic.
If you can enforce That said, from experience, if you need to enforce versions, it's better to do that at the time of providing the toolchain into the build environment, including in providing the container. This avoids any possibility of environment misconfiguration and inefficiencies resulting from needing to download and perform a toolchain switch. |
GOTOOLCHAIN
option to respect the runtime version specified in the toolchain
directive of the go.mod file
|
In general we don't want to make it too easy for people to downgrade their go versions. GOTOOLCHAIN=go1.23.4 is like 'go get go@1.23.4' and selects an exact version. |
Proposal Details
Currently, the local Go runtime determines the actual Go version to use by checking the
toolchain
directive in thego.mod
file whenGOTOOLCHAIN=auto
is set. If the local Go runtime is newer than the version specified in thetoolchain
directive, it defaults to the local Go version. This behavior aligns with the Go Toolchain documentation.However, in some cases—such as in production environments—it may be necessary to enforce a specific Go runtime version, even though Go maintains strong forward and backward compatibility. For example, if the
toolchain
directive specifies1.22.8
but the Go runtime in the container is1.23.2
, the actual version used would be1.23.2
. This could lead to unexpected issues if the container runtime is updated (eventoolchain
is never changed), which should sometimes be blocked to prevent unexpected factors.While setting
GOTOOLCHAIN=<version>
is a valid solution but usually thisGOTOOLCHAIN
environment variables might be in disorder in a project; this is against the DRY principle. I believe it would be more convenient to have an option that always respects the version specified in thetoolchain
directive as the actual runtime version. This would allow developers to control the Go version for an application simply by modifying the version in thetoolchain
directive.As a potential solution, how about introducing an option like
GOTOOLCHAIN=mod
to achieve this behavior?The text was updated successfully, but these errors were encountered: