cmd/go: consider including Go's own version in 'go env'

[mvdan]

go env -json tells me a lot about the user's Go setup and environment, and in a format that's easy to parse. Unfortunately, go version is missing there, so if I want to fetch that I need a separate exec call.

I wonder if we could add it to go env, similar to other "not really an env var" lines like GOMOD, GOEXE, or GOHOSTARCH. For example:

$ go version
go version go1.15 linux/amd64
$ go env -json
[...]
    "GOVERSION": "go1.15",
[...]

It would not include the string prefix go version, since it's redundant, nor the linux/amd64 pair, since that's already as GOHOSTOS/GOHOSTARCH in go env.

I'm not making this a proposal for now, since the idea seems pretty simple.

/cc @bcmills @jayconrod @matloob for cmd/go

[ainar-g]

I'm very in favour of this. When I'm debugging builds on a remote machine or helping a colleague, I call go env and go version in tandem. Even the default issue template here on GitHub requires the output of both commands.

[mvdan]

That's a good point; just having to call go env would be pretty handy when debugging problems on other machines.

[mvdan]

On our last golang-tools call, @bcmills, @jayconrod, and @heschik raised a good point. The version reported by go version isn't the only interesting bit of information from the Go toolchain that tools would find useful. There's also the "Go language version" or major version used for build tags such as // +build go1.15. For the sake of clarity, let's call those GOVERSION and GOMAJORVERSION.

At the time of writing, if one runs Go 1.15.2, one could imagine:

$ go env
[...]
GOVERSION="go1.15.2"
GOMAJORVERSION="go1.15"

That seems simple enough. In the case of a stable release, they'll always share the first two semver components. However, it gets more interesting for devel builds. For example, with my current master build, as per src/internal/goversion/goversion.go showing const Version = 16:

$ go env
[...]
GOVERSION="devel +150bd4ffd4 Wed Sep 23 07:51:17 2020 +0000"
GOMAJORVERSION="go1.16"

We could bikeshed about the names, but it seems clear to me that both versions are useful to have, and they're clearly different.

[mvdan]

It seems like everyone agrees this would be a good change, so I'll do a CL this week in the hopes to get it into 1.16. We can bikeshed about the var names on Gerrit.

[rsc]

We shouldn't have two different variables. One should be enough, it should be GOVERSION, which should record the output of go version (with the 'go version' prefix and the goos/goarch suffix removed I assume).

There is a separate issue, which is that you can't tell from go version what the base version of Go is. Changing the output to do that seems fine to me. I think I would suggest changing the git hash to "go1.Version+Hash", as in:

go version devel go1.16+a8a337f1f4 Tue Oct 20 16:43:37 2020 -0400 darwin/amd64

[bcmills]

We could close the not-quite-semver gap a little bit by using - instead of + to separate the hash: then it would read as a SemVer prefix with a pre-release suffix, which seems like not a terrible fit for the intended meaning.

[rsc]

I'm OK with '-' because the string means "before Go 1.16" not "after Go 1.16".
But I don't want to claim any interest in closing the semver gap. :-)

[heschi]

Just for the record, I don't think it reliably means either before or after. We do bump the version about the same time the tree reopens these days, but if you're building 1.16.1 before it's been tagged, it's definitely not before 1.16, right?

Adding the "base version" to the version string should work for gopls as long as it's enforced by dist as much as possible. It might be nice to validate the VERSION[.cache] file .

[mvdan]

Do we agree to do both changes at once for 1.16? I feel like if we change the format of go env GOVERSION between 1.16 and 1.17, that would make the env var significantly less useful in 1.16.

[gopherbot]

Change https://golang.org/cl/264938 mentions this issue: cmd/dist: include "go1.x-" to devel go version strings

[dmitshur]

Making go version report more accurate version information for development versions is something that's been on my mind too, but I hadn't seen this issue.

@mvdan I wanted to ask if it's in scope of this issue to make it work for minor versions on release branches too?

For example, if Go is built at commit 8f14c1840d15233b7f3d08f0acf0b0559d465a56 (tip of release-branch.go1.15 as of this posting), go version will currently report go1.15.3, which is not true. Based on the pattern above, it could report:

go version devel go1.15.4-8f14c1840d15 Tue Oct 20 16:43:37 2020 -0400 darwin/amd64

Making that work may require doing something different, because unlike the main branch, release branches have a VERSION file committed. That's something that can be controlled on the side of release tooling, but need to consider people building from source. I wanted to ask since it may influence the overall direction.

[mvdan]

Based on the pattern above, it could report:

go version devel go1.15.4-8f14c1840d15 Tue Oct 20 16:43:37 2020 -0400 darwin/amd64

I don't think so - it would report go version devel go1.15-8f14.... That is, the added string is equivalent to what is matched against build tags. It's always goX.Y, never goX.Y.Z. This is also how my CL is currently implemented. One could also call this the "Go language version", as it's what's used in the go X.Y line in a go.mod file.

release branches have a VERSION file committed

Thanks, I didn't know that (just like I didn't know that builders similarly had a hard-coded version in them). The question then is - should such a build result in go version go1.15.3, or go version devel go1.15-8f14...? I would argue the latter, because the former is certainly wrong. So I imagine that the simplest solution is to just not commit VERSION files in release branches, and rely on git tags for fully finished releases.

If the worry is that some people might build with a source tarball without the git directory present, then perhaps the VERSION file could be added right when the tag is done, then removed again. Or, as a similar mechanism to not pollute the release branch with such add and remove commits, the commit to add VERSION and tag the release could be done as a fork of the release branch.