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.