go: cmd/go: version information is not structured enough for use by developer tools
Developer tools need to know what version of Go is in use for a variety of reasons. Two examples that have come up very recently:
- Gogland needs to know what language features to enable, such as vendoring and type aliases.
- Delve needs to know details of the runtime, such as where to find the G pointer in a thread’s registers, as well as what flags it can pass to the build system to generate good debug information.
If you’re using a released version, it’s relatively straightforward to parse the output of go version:
go version go1.8.3 linux/amd64 means you’re running 1.8.3. But we also do release candidates, which say go1.8rc1, and then sometimes we build off dev tags and get something like go1.8.3.typealias. And then for even more fun, devel builds:
go version devel +835dfef939 Wed Jul 26 13:29:59 2017 +0000 linux/amd64
which doesn’t help at all.
I don’t have a specific proposal, but there is a clear need for a structured way of determining at least the major/minor Go version in use, even for devel builds. More detailed information in some form could be valuable if, for example, we wanted Delve to be able to tell if a devel build contained a specific runtime change. That’s probably overkill though.
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Comments: 20 (20 by maintainers)
While in theory 1.8.0 and 1.8.3 ought to be the same, in practice, who knows? If we are going to introduce this kind of mechanism, it should probably have a way to report minor versions as well.
One use-case is when users are using currently Go 1.8.0 in their production servers and are testing Go 1.8.3 for upgrade. At that point there would be two Go releases which have the same
Go 1.8label but the user wouldn’t know which is which.