Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
davidwkeith opened this issue Aug 27, 2018 · 16 comments

Comments

Projects
None yet
10 participants
@davidwkeith
Copy link

commented Aug 27, 2018

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

This comment has been minimized.

Copy link
Author

commented Aug 27, 2018

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

@robpike

This comment has been minimized.

Copy link
Contributor

commented Aug 27, 2018

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

This comment has been minimized.

Copy link
Author

commented Aug 27, 2018

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 davidwkeith changed the title 1.11 is not a semver compliant version number `1.11` is not a semver compliant version number Aug 27, 2018

@davidwkeith

This comment has been minimized.

Copy link
Author

commented Aug 27, 2018

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

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

@robpike robpike closed this Aug 27, 2018

@robpike robpike reopened this Aug 27, 2018

@randall77

This comment has been minimized.

Copy link
Contributor

commented Aug 27, 2018

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

This comment has been minimized.

Copy link
Author

commented Aug 27, 2018

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

This comment has been minimized.

Copy link
Member

commented Aug 27, 2018

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

This comment has been minimized.

Copy link
Author

commented Aug 27, 2018

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

This comment has been minimized.

Copy link

commented Aug 27, 2018

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.

@bradfitz bradfitz added this to the Go1.12 milestone Aug 27, 2018

@bradfitz bradfitz changed the title `1.11` is not a semver compliant version number build: release Go 1.12 as Go 1.12.0 to be semver compliant? Aug 27, 2018

@davidwkeith

This comment has been minimized.

Copy link
Author

commented Aug 27, 2018

@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 comment has been minimized.

Copy link
Member

commented Aug 28, 2018

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

/cc @rsc

@felicianotech

This comment has been minimized.

Copy link

commented Sep 8, 2018

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

This comment has been minimized.

Copy link
Member

commented Sep 9, 2018

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

@rsc

This comment has been minimized.

Copy link
Contributor

commented Sep 26, 2018

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

This comment has been minimized.

Copy link
Member

commented Jun 5, 2019

@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

This comment has been minimized.

Copy link
Author

commented Jun 5, 2019

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.