-
Notifications
You must be signed in to change notification settings - Fork 17.5k
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
Comments
For reference, the lack of patch version is currently a feature request on #237. |
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. |
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 |
1.11
is not a semver compliant version number
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. |
This hasn't worked in forever. |
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. |
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". |
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. |
The output of The documentation of
So your incorrect expectation that |
1.11
is not a semver compliant version number
This question has come up previously in discussions outside the GitHub issue tracker. /cc @rsc |
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 |
@FelicianoTech we are waiting on @rsc to respond here, because this has been discussed before. |
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. |
@davidwkeith In case it's helpful to you, if you'd like to parse the existing Go version numbering scheme, you may find |
@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 |
Sorry if this is somewhat off-topic, but since you said you're using node, and I assume the
Or on the command line:
|
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
)?What did you do?
Tried to upgrade my software to go1.11, but it relied on
github.com/coreos/go-semver
to manage polyfills.What did you expect to see?
1.11.0
What did you see instead?
panic: 1.11 is not in dotted-tri format
The text was updated successfully, but these errors were encountered: