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 should migrate away from the custom GO_VERSION to the standardized GOTOOLCHAIN (and also stop overriding it in the makefile by default versus telling users to set toolchain in their go.mod, but allow callers to override the module with GOTOOLCHAIN)
I would propose a transition period where GO_VERSION is read if set and a warning is produced while translating it to the GOTOOLCHAIN equivilant.
I've been thinking about how to approach this for kubernetes, one caveat remains that toolchain is per-module if not overridden by the env, versus GO_VERSION right now means the default is a single repo-scoped value (for multi-module repos).
The user overridden GOTOOLCHAIN or GO_VERSION would easily remain repo-scoped, but the default value would not and some diligence is needed to ensure all modules are in sync.
The text was updated successfully, but these errors were encountered:
We should migrate away from the custom GO_VERSION to the standardized GOTOOLCHAIN (and also stop overriding it in the makefile by default versus telling users to set
toolchain
in their go.mod, but allow callers to override the module withGOTOOLCHAIN
)I would propose a transition period where
GO_VERSION
is read if set and a warning is produced while translating it to the GOTOOLCHAIN equivilant.I've been thinking about how to approach this for kubernetes, one caveat remains that toolchain is per-module if not overridden by the env, versus GO_VERSION right now means the default is a single repo-scoped value (for multi-module repos).
The user overridden GOTOOLCHAIN or GO_VERSION would easily remain repo-scoped, but the default value would not and some diligence is needed to ensure all modules are in sync.
The text was updated successfully, but these errors were encountered: