cmd/go: `mod edit -go` is incompatible with `env GOVERSION` and the `go/version` package

[mvdan]

$ go env GOVERSION
go1.26.0
$ go mod init test
go: creating new go.mod: module test
$ cat go.mod
module test

go 1.25.0
$ go mod edit -go=$(go env GOVERSION)
go mod: invalid -go option; expecting something like "-go 1.26.0"

go env GOVERSION is generally consistent with https://pkg.go.dev/go/version, which is nice, however the string used by go mod edit does not include the "go" prefix, making it incompatible.

It would be nice if this were made consistent. Internally, the toolchain already knows how to do this, I'm sure; it's just not very well exposed via the CLI.

I think the solution is for any CLI flag or argument which accepts a Go version to also accept the format with the "go" prefix, including go mod edit -go.

Note that the reverse issue also exists, i.e. go mod edit -json shows "Go": "1.25.0", which is again incompatible with https://pkg.go.dev/go/version. However, this is less of a pain point, at least for my scripting use cases.

[gabyhelp]

Related Issues

• cmd/go: consider including Go's own version in 'go env' #41116 (closed)
• cmd/go: on malformed "go mod edit -go", suggest current version of go, not hardcoded 1.12 #32286 (closed)
• cmd/go, x/mod: "invalid go version" message mentions old version format #61888 (closed)
• go/version: package for handling Go version strings #62039 (closed)
• cmd/go: change `go mod init` default go directive to 1.(N-n).0 #74748 (closed)
• cmd/go: add a `go mod edit -f` flag akin to `go list -f` #51757
• go/version: does not support the `X:` suffix from `go env GOVERSION` #75953 (closed)
• cmd/go: misleading error for a version following the module directive in go.mod #30145 (closed)
• cmd/go: should Go version be part of the go.mod specification? #23969 (closed)

Related Code Changes

• cmd/go: introduce the GOVERSION env variable

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[mvdan]

It's also worth noting that GOTOOLCHAIN is already consistent with the go/version format.

Interestingly, go get go@go1.26.0 works today, even though go mod edit -go=go1.26.0 does not.

[sudomateo]

go env GOVERSION is generally consistent with https://pkg.go.dev/go/version

When is it inconsistent?

however the string used by go mod edit does not include the "go" prefix, making it incompatible.

Taking the logic here and in the rest of this feature request, the go directive within go.mod does not use the goX.Y.Z format either. Is that incompatible too?

Note that the reverse issue also exists, i.e. go mod edit -json shows "Go": "1.25.0", which is again incompatible with https://pkg.go.dev/go/version. However, this is less of a pain point, at least for my scripting use cases.

What are your personal scripting use cases? Perhaps the community has something to potentially relate to if you list them.

[mvdan]

When is it inconsistent?

master builds are probably not valid per go/version:

$ go env GOVERSION
go1.27-devel_ff023a3341 2026-02-28 03:17:49 -0800

This probably ought to get fixed one way or another too, but I'm not personally affected by this.

Taking the logic here and in the rest of this feature request, the go directive within go.mod does not use the goX.Y.Z format either. Is that incompatible too?

I don't think rewriting all go.mod files to say e.g. go go1.25.0 is worthwhile or useful at this point. The stutter also feels a bit silly. The suggestion in this thread is purely about further relaxing the CLI so that the "go" prefix is consistently allowed.

What are your personal scripting use cases? Perhaps the community has something to potentially relate to if you list them.

The original post has the example: go mod edit -go=$(go env GOVERSION) to bump the current module to the current language version. One could argue that go get go@$(go env GOVERSION) works too, but it seems odd to me that one command accepts the now-standard format while the other does not.

[sudomateo]

Go itself is confused as to whether it's all in on semantic versioning. There are commands that favor goX.Y.Z over X.Y.Z and vice versa. Relaxing the CLI to accept both sounds good on paper, but in practice all it does is further enable the confusion. The confusion is compounded with poor CLI ergonomics (e.g., help subcommand versus --help flag) and limited CLI help text (e.g., linking to web docs). I'd personally rather see time and effort go to making Go more consistent rather than enabling bifurcation.

[mvdan]

I'm sorry but I disagree. Go versions themselves have never been semver, and this was already discussed at length and rejected in #32450. The current format, which go/version implements, was proposed later in #57631 and adopted.

This issue is just about making the CLI consistently accept this standard format.

[sudomateo]

I'm sorry but I disagree.

I know you disagree, hence your proposal. I'm here to offer an alternative perspective from the community so that there's actual discussion on these issues rather than the same few people steamrolling others.

Go versions themselves have never been semver, and this was already discussed at length and rejected in #32450. The current format, which go/version implements, was proposed later in #57631 and adopted.

I read both of these in their entirety and #32450 leaned more in favor of accepting the proposal. The comments there showcase exactly the confusion and bifurcation I'm talking about. There's Mr. Pike pushing for consistency with the broader ecosystem and Mr. Cox showcasing the negative effects of bifurcation to date. Granted, I'm not here to revive any of these discussions on this specific proposal but linking to these didn't help this proposal the way you seem to think it did.

This issue is just about making the CLI consistently accept this standard format.

Respectfully, the format cannot be standard if the Go language itself is confused on where and how to use it.

[mvdan]

OK. Again, I'm not sure exactly what your stance is on this particular small suggestion I am making here. I'm sorry that you feel like I'm steamrolling you, so I will stop responding for now.

[sudomateo]

OK. Again, I'm not sure exactly what your stance is on this particular small suggestion I am making here. I'm sorry that you feel like I'm steamrolling you, so I will stop responding for now.

I don't think that you are steamrolling anyone and I'm not trying to pick a fight with you. I appreciate the work you've done thus far and I'm sure you're tired dealing with the maintenance burden of open source project and all that comes with it. I've just read too many discussions that were on the fence and went in a direction that effectively ignored the community's feedback. I'm speaking up where I can now.

My point for this proposal, and others really, is that these little changes accrete and put Go in a position where it no longer feels like a engineered language. I'd like us to fix the core issue when possible, but I know that's not always practical.

[mwriter]

I also took care of this problem, and as a result, I wrote my own implementation of working with versions.
It turned out something similar on

type Version struct { ... }

func (v Version) Compare(v2 Version) int {
	return version.Compare(v.GoString(), v2.GoString())
}

func (v Version) GoString() string {
	return "go" + v.String()
}

func (v Version) Lang() string {
	return version.Lang(v.GoString())
}

func (v Version) String() string {
	...
}

And I think it's still more correct to work with the original versions without the prefix. It seems to me that it was a mistake to bind to the prefix, and we need to get away from this. Although I understand that this is hardly possible.

[mwriter]

My point for this proposal, and others really, is that these little changes accrete and put Go in a position where it no longer feels like a engineered language.

It's called legacy, and it's almost unavoidable. Python even deliberately severed all ties with the previous language specification.
In the case of Golang, it's much easier to create various custom wrappers over the standard library that help standardize such things for internal corporate standards.