Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
proposal: x/website: have endpoint to query for the latest bugfix version #36898
#34864 covers documenting the endpoint better. Right now, it's documented at https://godoc.org/golang.org/x/website/internal/dl. Listing the versions is very useful, so that endpoint is great.
However, there is one common operation that's not covered by the endpoint: showing the latest Go patch release for a major version like 1.12 or 1.13. This is useful to quickly download and install such a latest version, or to use it for a line like
CI systems like Travis or GitHub Actions allow you to specify
However, this gets harder when one is writing shell script one-liners, or portable scripts in general. There's just no way to do it in POSIX Shell or even Bash, let alone shells for other systems.
We don't want the result to be JSON, for the reasons laid out before. So the first step is adding
To support querying for the latest bugfix version for a particular "major" release like 1.12, we'd add another parameter
Another option would be to rely more on the shell, and simply add
Thanks for filing this.
I agree the
Since you haven't discussed it explicitly in the original issue, I'll copy what I wrote in #36886 (comment):
I want to ask what you think about relying on the maintner API for this? Its
It's still an option to expose the same information from the golang.org/dl?mode=json API, which this issue is about investigating, but I wanted to ask a few of those questions first.
I want to make use of this in scripts, so it should be plan HTTP+plaintext, just like the existing endpoint with
I'd prefer this to live under
Note that, as said before, the replacement needs to support REST and plaintext endpoints too, otherwise we'd be losing valuable features.
I imagine a large amount of the use cases (including mine) involve using the release, i.e. downloading it. So yeah, the feature should show the latest fully released version.
It's worth noting that https://golang.org/dl/?mode=json has the information.
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.
[Copied from #38150. Since this is the older issue, let's put the discussion here.]
Thanks for your reply. Since your reply was written for the duplicate issue, I think some points need clarifying.
In general, I agree. But note that I propose allowing to query the latest
I disagree - see my reasoning in the original proposal.
@mvdan, the original comment above says:
But this is not true. Bash and other systems can use jq, or people can use a simple Go program invoked from the shell, maybe even with go run. (Bash doesn't do HTTP requests internally yet does it? I believe this discussion assumes invoking other tools like curl already.)
You said in the comment at the top that CI systems are fine as is, since they can run basic computation even more easily than shell scripts can.
Even after rereading your original comment atop this issue, I'm not sure I understand what the argument is for making resolving 1.13.x easier for bash.
It's true that the original example requires some tool to download a file via HTTP (like curl), though that's generally possible to do out of the box on most machines or docker images. Comparatively,
I should have clarified that this is generally for CI environments that don't have a Go version installed.
Yes and no. Some CI systems like GitHub Actions and Travis wrote their own code to figure out what the latest version for Go 1.14.x is. I can use that, yes, but then I don't have that feature if I use some other CI system, or if I run my own CI. I could write this software myself, depending on jq, python, Go, or some other tool that can process json, but it feels like I shouldn't need to reinvent the wheel here :)
That's what I tried to answer in #36898 (comment). A short version of that is - people find it useful for testing on CI.
Here's a perhaps simpler counter-proposal. Only add a
That way, in mostly-portable shell, one can get the latest 1.14.x by simply doing a
I think this is a good goal. I filed issue #38773 related to this. Perhaps it will be easier to evaluate any proposed changes to the
First, we really need to document the current mode=json endpoint.
Plenty of other ways too (can do the whole thing with sed or perl too, assuming the CI has at least one of those).
#34864 is the issue for documenting mode=json better.
Based on the discussion above, this issue (a latest-version endpoint or a text mode) sounds like a likely decline.