proposal: dl: add "latest patch version" runner

[SamWhited]

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.

[rsc]

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]

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]

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]

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

[andybons]

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]

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]

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]

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]

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]

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"

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

[mvdan]

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]

@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]

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]

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]

@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.