Tighten up Go version specification

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: https://github.com/golang/go/issues/27255#issuecomment-424812737

(I note the discussion in https://github.com/golang/go/issues/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.

[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!

[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 https://github.com/actions/setup-go/issues/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.