You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
Proposal
Add a single download alias to the current download hosting server:
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.
Previous Proposal
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.
The text was updated successfully, but these errors were encountered:
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.)
Motivation
Setting up a Go release in a new environment requires using download link with a specific version, e.g.
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 thedl
is simple but requires a machine to install a go release beforehand.Proposal
Add a single download alias to the current download hosting server:
For instance, at the moment:
redirects to:
Moreover, In the featured downloads https://golang.org/dl/#featured, one can use the alias for the latest stable release.
Further thoughts
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.
Previous Proposal
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.
The text was updated successfully, but these errors were encountered: