Setting up a Go release in a new environment requires using download link with a specific version, e.g.
GOVERSION=go1.14.1
wget https://dl.google.com/go/$GOVERSION.linux-amd64.tar.gz
This also requires a developer to change their CI scripts for upgrading the latest Go release. Instead, a download alias makes install and rebuild always up-to-date.
Besides, the OS distribution is not always up-to-date, therefore apt install go doesn't really download the latest version.
The usage of go get for the dl is simple but requires a machine to install a go release beforehand.
Add a single download alias to the current download hosting server:
https://dl.google.com/go/latest?os=GOOS&arch=GOARCH
For instance, at the moment:
https://dl.google.com/go/latest?os=darwin&arch=amd64
redirects to:
https://dl.google.com/go/go1.14.1.darwin-amd64.tar.gz
Moreover, In the featured downloads https://golang.org/dl/#featured, one can use the alias for the latest stable release.
Some may fight against that a download alias may permit implicit upgrading to the latest Go release if a new Go release came out, which can cause an unexpected CI issue.
This proposal argues that this is expected behavior and developers or operators use this link by accepting the use of the latest release for goods. The download alias does not break any existing Go scripts and therefore dev/ops can still use the old patterns of downloading a specific version of Go, as pasted in the motivation section.
A previously rejected issue #29984 proposed to add the latest patch version which may lead to imprecision and confusion of the download version. The latest path will have to apply to all existed releases and future releases, therefore it can be verbose. Furthermore, a user still needs to figure out which version are they downloading. In this proposal, it is much simplified and easy to do because it only proposes adding one more link to the current release flow. Once and for all.
This seems like an almost exact duplicate of https://github.com/golang/go/issues/36898 :)
It's worth noting that https://golang.org/dl/?mode=json has the information.
This also requires a developer to change their CI scripts for upgrading the latest Go release.
I guess the question is: do you want your CI system to break automatically the moment we release a new version of Go (if the CI system is fetching "latest"), or do you want to control when the update happens? In general we've encouraged the latter and discouraged references like "latest".
Given that "latest" _is_ possible already with the JSON (and shell scripts can use jq), and that maybe "latest" shouldn't be made trivial to discourage these kinds of blind updates, maybe things are just right as is.
(We also can't easily change dl.google.com, which is about far more than just Go, although we could change things on golang.org that redirect.)
Copying the above comment to #36898 and closing this as duplicate of that.
Most helpful comment
This seems like an almost exact duplicate of https://github.com/golang/go/issues/36898 :)