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

Change https://golang.org/cl/247524 mentions this issue: internal/dl: add includes values stable, unstable, archive

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.

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.

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)?