cc @dolmen @ConradIrwin @golang/go-command
When we added support for the tool directive, we should have rejected building a work (main) module that declared a go version earlier than 1.24 and had a go directive. The current behavior is that a work module that has a tool directive will not build with a go toolchain 1.23.X or earlier (because we parse the go.mod file strictly), but will with a toolchain 1.24 or later.
We're changing the 1.27 behavior to reject a work module that has a tool directive but a go directive 1.23.X or earlier. We want to also change go mod tidy to update the go directive in the go.mod but that will break an invariant that go mod tidy doesn't change a working module. Because Go 1.24 will allow a go 1.23 module with a tool directive (and will not change it with go mod tidy), we can consider it a working module, which go mod tidy shouldn't change in a new Go version.
This is a bug and arguably we should undo it: that would mean (a) rejecting tool directives in go.mod files declaring Go 1.23 or earlier, and backporting the change to Go 1.25 and Go 1.26 and (b) having go mod tidy add a minimum version requirement on Go 1.24.
But because this could break some modules, this should go through the Go command working group and the proposal commitee.
cc @dolmen @ConradIrwin @golang/go-command
When we added support for the
tooldirective, we should have rejected building a work (main) module that declared a go version earlier than 1.24 and had agodirective. The current behavior is that a work module that has a tool directive will not build with a go toolchain 1.23.X or earlier (because we parse the go.mod file strictly), but will with a toolchain 1.24 or later.We're changing the 1.27 behavior to reject a work module that has a tool directive but a go directive 1.23.X or earlier. We want to also change
go mod tidyto update the go directive in the go.mod but that will break an invariant thatgo mod tidydoesn't change a working module. Because Go 1.24 will allow ago 1.23module with atooldirective (and will not change it withgo mod tidy), we can consider it a working module, whichgo mod tidyshouldn't change in a new Go version.This is a bug and arguably we should undo it: that would mean (a) rejecting tool directives in go.mod files declaring Go 1.23 or earlier, and backporting the change to Go 1.25 and Go 1.26 and (b) having
go mod tidyadd a minimum version requirement on Go 1.24.But because this could break some modules, this should go through the Go command working group and the proposal commitee.