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

Tighten up Go version specification #63

Open
myitcv opened this issue Jul 13, 2020 · 7 comments
Open

Tighten up Go version specification #63

myitcv opened this issue Jul 13, 2020 · 7 comments
Labels
feature request New feature or request to improve the current logic investigation The issue is under investigation

Comments

@myitcv
Copy link

myitcv commented Jul 13, 2020

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
Copy link
Author

myitcv commented Jul 13, 2020

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
Copy link

ncw commented 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
Copy link
Contributor

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

@Sergey-Murtazin Sergey-Murtazin added the feature request New feature or request to improve the current logic label Oct 19, 2021
@myitcv
Copy link
Author

myitcv commented Oct 22, 2021

@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
Copy link

mvdan commented Mar 3, 2022

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
Copy link
Contributor

dsame commented Aug 30, 2023

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.

@dsame dsame added needs eyes investigation The issue is under investigation and removed needs eyes labels Aug 30, 2023
@dsame dsame removed their assignment Sep 1, 2023
@mvdan
Copy link

mvdan commented 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 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request New feature or request to improve the current logic investigation The issue is under investigation
Projects
None yet
Development

No branches or pull requests

6 participants
@dsame @ncw @myitcv @mvdan @Sergey-Murtazin and others