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

proposal: dl: add "latest patch version" runner #29984

Closed
SamWhited opened this issue Jan 30, 2019 · 15 comments
Closed

proposal: dl: add "latest patch version" runner #29984

SamWhited opened this issue Jan 30, 2019 · 15 comments

Comments

@SamWhited
Copy link
Member

SamWhited commented Jan 30, 2019

In CI it would be convenient to have a way to easily download the latest patch version of some minor version of Go and setup the correct PATH without having to specify a specific patch version that would need to be bumped in the CI config every time Go was released. I would like to propose that this be added to the go-gettable packages at golang.org/dl using ".x" for the patch version.
For example, running:

go get -u golang.org/dl/go1.11.x

would install a new binary called go1.11.x alongside existing versions such as go1.11.5 and gotip.

I see two possible ways to implement this:

Adding support for ".x" versions to dl/internal/version and then generating a .x version as necessary.
When a ".x" version is run, it would scan ~/sdk for any versions of Go that start with "go1.11" (or whatever the prefix was), pick the latest one, and run that.
When go1.11.x download is run, it would download and parse https://storage.googleapis.com/go-builder-data/dl-index.txt and compare the versions there to whatever is in the ~/sdk directory at the moment. If there is a newer one it would download it to the correct location for that specific version (eg. ~/sdk/go1.11.5).

Alternatively, when genv command could be updated to always generate a go1.major.x version whenever it is run that corresponds to the latest version in the tree (eg. internally it would be hard coded to a specific version, just the name would include ".x"). Each time it is rerun, this packages hard coded version would be bumped and the user would have to go get -u the .x version over again to bump the binary to the latest version, then possibly run go download again to download the distribution to the ~/sdk tree.

EDIT: actually, the builder index doesn't appear to be up to date and https://golang.org/dl/?mode=json only contains the latest two supported versions. We'd have to find somewhere else to get version information or fix the builder data.

@ianlancetaylor ianlancetaylor changed the title dl: proposal: add "latest patch version" runner proposal: dl: add "latest patch version" runner Jan 30, 2019
@gopherbot gopherbot added this to the Proposal milestone Jan 30, 2019
@rsc
Copy link
Contributor

rsc commented Jan 30, 2019

Note that go get -u golang.org/dl; go list golang.org/dl/... (or just the second half with modules) will show what's available. That's an easy way to check for updates, potentially.

The current precision of "each installed go command name refers to exactly one possible version" seems worth preserving. It might be better to let users introduce ambiguity as they see fit.

@andybons
Copy link
Member

There is also a JSON endpoint on golang.org/dl that shows you all available versions:

https://golang.org/dl/?mode=json

One could query that, determine the latest version, then run go get -u

@SamWhited
Copy link
Member Author

SamWhited commented Jan 30, 2019

Note that go get -u golang.org/dl; go list golang.org/dl/... (or just the second half with modules) will show what's available. That's an easy way to check for updates, potentially.

That's a good point; I could probably be doing that from bash right now. It would still be a lot more convenient to just have a single binary that gives me the latest of a specific version of Go, but I could go either way depending on whether you think the patch is worth it.
I threw a patch together for using the latest version (it doesn't do the download yet since I couldn't find a machine readable endpoint), and it was fairly simple though.

There is also a JSON endpoint on golang.org/dl that shows you all available versions:

That only shows current supported versions; that's good enough for me, but if we have a go1.11.x command I suspect we'd want it to keep working after Go 1.11 is deprecated. I'd be happy to submit a patch to just make that include all versions too though if that's an option. I suppose that's a question for the website repo though.

EDIT: or maybe you meant I could do that in CI; that's true, I'd just rather use go get instead of having to install jq or similar, but I could go either way.

@gopherbot
Copy link

Change https://golang.org/cl/160458 mentions this issue: internal/version: support latest patch version

@andybons
Copy link
Member

That only shows current supported versions; that's good enough for me, but if we have a go1.11.x command I suspect we'd want it to keep working after Go 1.11 is deprecated. I'd be happy to submit a patch to just make that include all versions too though if that's an option. I suppose that's a question for the website repo though.

Ah right. I was mistakenly running under the assumption that golang.org/cl/155740 had been landed (show all versions if you specify a query param).

or maybe you meant I could do that in CI; that's true, I'd just rather use go get instead of having to install jq or similar, but I could go either way.

You could also write a Go program with no external dependencies that displayed what you need (without having to download jq), though I understand the desire to have it baked into go.

@SamWhited
Copy link
Member Author

SamWhited commented Jan 30, 2019

golang.org/cl/155740

I missed that one; thanks. Following.

You could also write a Go program with no external dependencies that displayed what you need (without having to download jq)

That's what I'm proposing here :) (sorry, I know what you mean)

@SamWhited
Copy link
Member Author

Updated https://golang.org/cl/160458 with a naive implementation that assumes we can use the JSON endpoint just to give everyone an idea of how much extra stuff is involved. If this proposal is accepted, I'm happy to polish it up a bit.

@bcmills
Copy link
Contributor

bcmills commented Feb 4, 2019

The current precision of "each installed go command name refers to exactly one possible version" seems worth preserving.

Note that we already have some ambiguity from golang.org/dl/gotip.

@bcmills
Copy link
Contributor

bcmills commented Feb 4, 2019

Personally, I think it's pretty confusing to have the first patch version in the 1.11 line be named go1.11 rather than go1.11.0, especially given that go get some/module@1.11 in module mode does mean “the latest patch release of some/module with minor version 1.11”. The lack of minor-version on the first release buries a major clue to the user that there might be more recent versions available.

I would like to see us release Go 1.12 as go1.12.0 instead of go1.12.

@thepudds
Copy link
Contributor

thepudds commented Feb 5, 2019

FWIW:

  1. I agree with @bcmills that go1.11 or go1.12 is unnecessarily confusing and unnecessarily ambiguous. Quoting @mvdan:

I too have wished for 1.11 to be 1.11.0 for a while. Too many users think they're running the latest 1.11 because they're on 1.11. "What do you mean the latest 1.11? I am on 1.11"

  1. This was tracked in the now closed build: release Go 1.12 as Go 1.12.0 to be semver compliant? #27255.

@mvdan
Copy link
Member

mvdan commented Feb 5, 2019

  1. This was tracked in the now closed build: release Go 1.12 as Go 1.12.0 to be semver compliant? #27255.

I think that proposal was more agressive. We don't need to follow semver. For example, we can keep on calling 1.12.0 a major release, which doesn't follow semver. And we can keep on calling versions go1.12.0 instead of v1.12.0 or 1.12.0.

Russ also said in that issue that he doesn't see a clear advantage in changing the release process. I think in these few comments we do show that there's a confusion among many users as to what 1.11 or 1.12 mean.

Should we open a new proposal? It would be different to #27255, and this way we don't spam this issue, which is only somewhat related.

@thepudds
Copy link
Contributor

thepudds commented Feb 5, 2019

@mvdan that is a fair point that the suggestion in #29984 (comment) is not identical to #27255.

Personally, I think a more focused proposal makes sense.

@rsc
Copy link
Contributor

rsc commented Feb 6, 2019

It seems like we should keep the precision of the current scheme and let people give meaning to things like go1.12.x as they see fit, layered on top. Let's not do this.

@SamWhited
Copy link
Member Author

In that case, can we perhaps provide suggestions for getting an up to date version in CI? Because right now it's properly a pain.

@thepudds
Copy link
Contributor

thepudds commented Feb 6, 2019

@SamWhited I haven't digested this whole conversation, so sorry in advance if this is unhelpful...

You could look at using https://github.com/travis-ci/gimme, which works outside of travis and I think is MIT licensed, or alternatively some other options like asdf, etc. (Not sure if you are targeting Windows as well, but I think gimme might even work with cygwin or WSL or similar on Windows).

gimme in particular supports some flexibility in terms of how to ask what version of Go should be download, e.g.:

gimme is a shell script that knows how to install go.
...
Gimme now supports the concept of .x, as a version suffix; eg, 1.10.x might be 1.10 before the release of 1.10.1 but become 1.10.1 once that's available.

@golang golang locked and limited conversation to collaborators Feb 6, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

7 participants