build: release Go 1.12 as Go 1.12.0 to be semver compliant?

[davidwkeith]

What version of Go are you using (go version)?

go version go1.11 darwin/amd64

Does this issue reproduce with the latest release?

Yep

What operating system and processor architecture are you using (go env)?

GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/dwk/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/dwk"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/zg/cc0sk95s6mjc7h3ywtrvcv340000gn/T/go-build303142424=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

Tried to upgrade my software to go1.11, but it relied on github.com/coreos/go-semver to manage polyfills.

package main

import (
	"fmt"
	"runtime"
	"strings"

	"github.com/coreos/go-semver/semver"
)

func main() {
	goVerStr := strings.TrimPrefix(runtime.Version(), "go")
	fmt.Println(semver.New(goVerStr))
}

What did you expect to see?

1.11.0

What did you see instead?

panic: 1.11 is not in dotted-tri format

[davidwkeith]

For reference, the lack of patch version is currently a feature request on #237.

[robpike]

RubyGems and Node at least handle versions like 1 and 1.0 (and worse; Ruby even handles 1.2.3.4 and it doesn't mean what you think.)

Semver is ideal but this is the internet, so you basically cannot expect compliance.

[davidwkeith]

If this was some person's individual project, I would completely agree. Now I need to patch a ton of software just to do a patch upgrade. That is not the promise of Go.

In contrast, JavaScript packages do this well through both npm and yarn.

[davidwkeith]

For reference, the following tools have issue with this scheme:

• Travis: I don't have any idea what to do with '1.11.0'.
• sqlx: tried a patch to remove polyfill on new GoLang versions
• go-semver: as reported

Likely others, basically broke many semver packages by not adding a ".0" to the end of the version string.

[randall77]

This hasn't worked in forever.
The package github.com/coreos/go-semver/semver can't handle all the ".0" versions of Go releases, back to at least 1.7.
Perhaps you should file a bug against that package.

[davidwkeith]

But @travis-ci also can't handle truncated version strings. Thus my automated tooling needs to know which tools are SemVer compliant and which are not.

This is not true for other ecosystems, most notably JavaScript/Yarn. which is the literal wild west of software development.

[dsymonds]

What's your automated tooling? Presumably it needs to know about the travis YAML format to be able to write that, so having it know that the Go version isn't necessarily full semver doesn't seem like a big step. It's pretty easy to fix for travis, too: if there's only one dot, add ".x".

[davidwkeith]

Our tools read the YAML in to know which version of GoLang to expect and install for non-GoLang engineers who just want to run functional tests locally. We use go-semver to parse the version string. Not a huge amount of work to fix, and one could argue that go-semver should support reasonable non-compliant version strings. However "1.11" is ambiguous and could mean "1.11.x" or "1.11.0", depending on how the tool interpreted it.

And while tiny versions shouldn't matter for most systems, some software needs to be locked down for certification. Tools parsing files to log dependencies need to support the version string, so if I used node-semver to generate that report, it also wouldn't work. (This is actually on our roadmap for future certification in with an industry standards body)

So basically a lot of trivial work for a many teams anytime a dot zero release of GoLang might exist, and since these releases are relatively rare, tools will continue to break during what should be a trivial upgrade.

[dolmen]

The output of go version has never been strictly major.minor.patch for "minor" releases. Go 1.10 says go1.10, not go1.10.0.

The documentation of runtime.Version() says:

Version returns the Go tree's version string. It is either the commit hash and date at the time of the build or, when possible, a release tag like "go1.3".

So your incorrect expectation that runtime.Version() is a semver is the issue. So of course you have to fix your code.

[davidwkeith]

@dolmen No problem changing my code to work around this, just suggesting a way to improve the ecosystem a bit when I noticed an issue.

@bradfitz Much better title, than you.

[myitcv]

This question has come up previously in discussions outside the GitHub issue tracker.

/cc @rsc

[FelicianoTech]

Practice what you preach should apply here. Fully embracing SemVer would be great. I started a forum discussion for this as well here: https://forum.golangbridge.org/t/shouldnt-go-release-under-semver/10500

[myitcv]

@FelicianoTech we are waiting on @rsc to respond here, because this has been discussed before.

[rsc]

We have an existing, established numbering scheme. Nothing that consumes these numbers needs them to be semver, especially since they have not been in the past. I don't see any argument for changing other than "some people like semver", which is not good enough. Note that 'go version' prints 'go1.12' not '1.12', so the 'go' prefix would also be problematic.

Note also that we call these "major releases" (because they are). A lot of messaging and existing code would change, for no benefit.

[dmitshur]

@davidwkeith In case it's helpful to you, if you'd like to parse the existing Go version numbering scheme, you may find version.ParseTag useful for that.

[davidwkeith]

@dmitshur That is outstanding, but for our use case we are consuming the version outside of the Go ecosystem (Node to be exact) For now we have written a parser for Go version strings that outputs a semver compliant string for our certification report. Give that Go's version string is functionally compliant with semver our lawyers don't need to explain yet another custom versioning scheme to regulators. We are extremely excited that Modules require semver compliance and merely wish for the same versioning standards throughout the ecosystem. (and across ecosystems, but that is a wider discussion of multi-industry regulatory sign offs and versioning best practices)

We could likely user version.ParseTag to generate YAML report from GoLang for the Node script to consume, it would clean things up a bit by abstracting the inconsistencies into language specific scripts. Probably what we should do for all the environments we use.

[isaacs]

Sorry if this is somewhat off-topic, but since you said you're using node, and I assume the semver module, this might be a handy method for you to be aware of:

> semver.coerce('go1.11').version
'1.11.0'
> semver.coerce('go1.11.1').version
'1.11.1'
> semver.coerce('go')
null

Or on the command line:

$ semver -c go1.11
1.11.0
$ semver -c go1.11.1
1.11.1
$ semver -c go
$ echo $? # failure exit if no version found
1

https://github.com/npm/node-semver#coercion