Repository navigation
Tighten up Go version specification #63
Description
The problem
I just tried to specify a build matrix that includes the latest beta, go1.15beta1 (using stable: 'false'). This failed because go1.15beta1 is not a valid version - 1.15.0-beta1 is the valid version according to setup-go (note the lack of go prefix, and the addition of .0-).
Background
Go versions are not semver: golang/go#27255 (comment)
(I note the discussion in golang/go#32450, but caution there is no specific plan)
For example, here is a list of valid Go versions (i.e. the result of go version):
go1.14go1.14.1go1.15beta1
The issue is that currently the user of setup-go has to perform two steps of translation: drop the go prefix, and think about how to translate to the "semver equivalent".
Proposal (breaking change)
I'd like to propose that specifying Go versions in the default case, i.e. an exact version specification, follows the output of go version. Hence:
- uses: actions/setup-go@v2
with:
go-version: 'go1.14'
means "use go1.14" rather than "use the latest go1.14.x".
If the semver-like specification is required, then I propose that a special prefix is used, perhaps ~:
- uses: actions/setup-go@v2
with:
go-version: '~^v1.14.0'
To my understanding this is a breaking change (hence v3 candidate) but I wanted to raise the issue for discussion in any case.
Activity
myitcv commentedon Jul 13, 2020
One further observation, Go modules refer to versions as follows:
v1.14.0-beta1. Note thevprefix. Updated the semver-like section of my previous comment to use thevprefix instead ofgo.In a similar vein I just made this suggestion: golang/go#32450 (comment)
ncw commentedon Jul 24, 2020
I've just been bitten by this too. Working out that the go release tagged 'go1.15beta1' needs
go-version: 'v1.15.0-beta1'is non trivial!Sergey-Murtazin commentedon Oct 19, 2021
Hi @myitcv ! Sorry for the late response!
Could you please clarify if the issue is still actual for you?
Thanks!
myitcv commentedon Oct 22, 2021
@Sergey-Murtazin
Yes, it remains an issue just as described in the original description.
mvdan commentedon Mar 3, 2022
Note that v3.0.0 has now dropped the
stableinput, so betas and RCs work by default. They have also switched to a slightly more consistent form of semver for the version strings. See #191.I still think it would be good to support Go versions as named by upstream, but at least now the behavior is more consistent.
dsame commentedon Aug 30, 2023
Hello @myitcv , maybe it is better to use
goprefix as an indicator of go versioning instead of adding special prefix to indicate semver versioning? This way we can keep backward compatibility.mvdan commentedon Jul 22, 2024
@dsame that would seem fair to me. Go versions are now also properly documented (implementation at https://pkg.go.dev/go/version, with doc links at the top), and they indeed begin with
goto make it very clear that they are not semver. Plus, Go's own git tags have thegoprefix, so it would be a 1-1 match with git tags as well.v-jitenderpalsingh commentedon Sep 11, 2026
Hi everyone,
Thank you for the suggestion and discussion.
Currently, the
go-versioninput supports SemVer-style specifications, including exact versions such as1.26.8, prereleases such as1.27.0-rc.2, ranges such as^1.26.0, and wildcards such as1.26.x.The
go-version-fileinput supportsgo.mod,go.work,.go-version, and.tool-versions. When ago.modorgo.workfile contains atoolchaindirective with a stable Go version,setup-gorecognizes the native Go version syntax, for example:However, prerelease versions written in native Go syntax, such as
go1.27rc2orgo1.18beta2, are not currently supported when read from thetoolchaindirective. To install a prerelease version, users can specify it directly through thego-versioninput using the supported SemVer-style syntax.We’d be interested to hear whether the currently available options address your use case.
arnested commentedon Sep 11, 2026
I opened #701 to address that.
AlekSi commentedon Sep 11, 2026
As far as I can tell, https://semver.org does not specify the latter two. While they might be familiar to users of other ecosystems, they are not familiar to Go users. I think it would be great to better document them, not just "SemVer version range syntax" (again, that's not actually SemVer) or "Wildcards".
v-jitenderpalsingh commentedon Sep 16, 2026
Thanks @AlekSi. By “SemVer-style,” I meant the syntax supported by node-semver, not that ranges and wildcards are defined by the SemVer specification. The actions/setup-go already lists these expressions and links to the package documentation, with additional examples in the advanced usage guide.