Tighten up Go version specification

[myitcv]

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.14
• go1.14.1
• go1.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.

[myitcv]

One further observation, Go modules refer to versions as follows: v1.14.0-beta1. Note the v prefix. Updated the semver-like section of my previous comment to use the v prefix instead of go.

In a similar vein I just made this suggestion: golang/go#32450 (comment)

[ncw]

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]

Hi @myitcv ! Sorry for the late response!
Could you please clarify if the issue is still actual for you?
Thanks!

[myitcv]

@Sergey-Murtazin

Could you please clarify if the issue is still actual for you?

Yes, it remains an issue just as described in the original description.

[mvdan]

Note that v3.0.0 has now dropped the stable input, 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]

Hello @myitcv , maybe it is better to use go prefix as an indicator of go versioning instead of adding special prefix to indicate semver versioning? This way we can keep backward compatibility.

[mvdan]

@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 go to make it very clear that they are not semver. Plus, Go's own git tags have the go prefix, so it would be a 1-1 match with git tags as well.