What version?
https://github.com/golang/website/commit/51b22ef31af8bf2cb877aab9d56031bae8313a18
Does this issue reproduce with the latest release?
Yes
What did you do?
Query https://golang.org/dl/?mode=json for stable releases and beta releases.
What did you expect to see?
A way to query the endpoint and get back the latest stable releases, i.e. go1.14.7 and go1.13.5, as well as the latest unstable/beta/release-candidate, i.e. go1.15rc2.
What did you see instead?
I see only a way to query the last two stable releases:
https://golang.org/dl/?mode=json
Or to query all releases that includes stable releases, unstable releases, and archived releases, of which there are many:
https://golang.org/dl/?mode=json&include=all
Comment From: leighmcculloch
Proposal
I think it would be useful for tools or development environments that automatically install the latest stable versions of Go to be able to easily query for the latest unstable releases. Using unstable releases is encouraged so that issues are found early and this is one way we could make that easier.
We could change the include option to take other values such as stable, unstable, and archived. The query value could support a comma-separated list of valid values so it would be possible to specify stable,unstable.
https://golang.org/dl/?mode=json&include=stable (default) https://golang.org/dl/?mode=json&include=stable,unstable https://golang.org/dl/?mode=json&include=all
This would be trivial to implement because the logic here is straightforward and malleable:
https://github.com/golang/website/blob/0108f0928b89f2c1b821381349f473db3f4cbfc4/internal/dl/server.go#L101-L107
Comment From: gopherbot
Change https://golang.org/cl/247524 mentions this issue: internal/dl: add includes values stable, unstable, archive
Comment From: dmitshur
It's true that the implementation for this is fairly small and easy. However, once we add support for this, it will become hard (nearly impossible) to remove and we'll need to maintain it indefinitely. So before making changes, I want to better understand what isn't possible (or is difficult or inefficient) now.
It seems to me that clients can request ?mode=json&include=all and perform any kind of filtering logic on their end. This is flexible and simple.
Can you please elaborate on why you think this change should be made? Is it about being able to reduce the size of the response needed to be delivered in some situations? Are there other factors?
I think it would be useful for tools or development environments that automatically install the latest stable versions of Go to be able to easily query for the latest unstable releases.
In what way is it not easy right now?
Also see #36898, #38773, and #37581 which may be related.
Comment From: leighmcculloch
In what way is it not easy right now?
It's not about reducing the size of the response, but folks who are automating the installation of Go in different environment may be, like me, doing this in scripts like bash scripts, etc. Right now because the default response is just the last two stable releases it is really simple to pipe that output to some other shell commands to install the stable releases.
I did not find it simple to filter a large set of JSON in bash. I'd have no problem doing this in Go, or other languages, so maybe I am just using the wrong tool for the job.
When release candidates and betas come out ideally it is as simple for people to install them as easily as stable releases by adding a parameter to the URL. It's definitely possible to parse all archived old releases to get at the release candidates/betas, but I think there's value in surfacing at least betas outside of the archived list so that it is easier for people to install all stable+RCs/betas since running the betas and RCs is encouraged. If it is encouraged it's worth lowering the barrier?
Another option would be to include the release candidates/betas in the default output but that'd be a breaking change and I'm not sure if that'd be appropriate.
Comment From: hyangah
We want this for vscode-go's Go release checking. In our case, the size of the response is important because vscode-go is watching this endpoint periodically. Currently, include=all output size is almost 1M and will keep growing. @dmitshur and @leighmcculloch, do you mind if we reopen this issue to reconsider the feature and sort out the details (e.g. include=stable,unstable)?