Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/website/internal/dl: provide json listing in version order #50201

Closed
zx2c4 opened this issue Dec 15, 2021 · 6 comments
Closed

x/website/internal/dl: provide json listing in version order #50201

zx2c4 opened this issue Dec 15, 2021 · 6 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@zx2c4
Copy link
Contributor

zx2c4 commented Dec 15, 2021

https://go.dev/dl/?mode=json gives all the current stable versions in descending order. Because they're sorted, this makes it easy to do things with tools like jq, without having to work out any finicky custom version-sort comparer.

https://go.dev/dl/?mode=json&include=all, however, gives all versions -- stable, archived, unstable -- out of order. This makes it very annoying to deal with from little tools like jq, since it's not trivial to sort version numbers.

Instead, we should sort the latter URL in the same descending order as the former URL.

CC @dmitshur

@gopherbot gopherbot added this to the Unreleased milestone Dec 15, 2021
@gopherbot
Copy link

Change https://golang.org/cl/371934 mentions this issue: internal/dl: show newer versions first in json listing

@dmitshur dmitshur changed the title x/website: provide json listing in version order x/website/internal/dl: provide json listing in version order Dec 15, 2021
@dmitshur dmitshur added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Dec 15, 2021
@dmitshur
Copy link
Contributor

Since the suggestion here is to make &include=all give versions in sorted order, I think that means #47367 needs to be fixed first. Otherwise when there's more than 1 pre-release version, it won't be possible to rely on their order.

@zx2c4
Copy link
Contributor Author

zx2c4 commented Dec 16, 2021

Didn't know about that; thanks. I'll look into it.

@zx2c4
Copy link
Contributor Author

zx2c4 commented Dec 21, 2021

@dmitshur - The CL should now handle everything mentioned. Is there anything else needed?

@dmitshur
Copy link
Contributor

Thanks. In general it looks good, I left minor comments.

As I mentioned on the CL, I expect this change to not to be disruptive, and one that we can make, but it's hard to know for sure in advance how smoothly it'll go. Since we're in a quiet week and right before holidays, let's defer next steps here to January.

@dmitshur dmitshur added NeedsFix The path to resolution is known, but the work has not been done. and removed NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. labels Dec 22, 2021
@zx2c4
Copy link
Contributor Author

zx2c4 commented Dec 23, 2021

Okay. Addressed your comments. Will plan on this being merged in January.

passionSeven added a commit to passionSeven/website that referenced this issue Oct 18, 2022
When include=all is used, archived versions (old) and unstable versions
(new) are appended to the list of returned versions. This makes the
order of the list rather awkward: current, old, new. This commit makes
the ordering a bit more natural: new, current, old. However, even like
that, releases will be out of order, because, for example, 1.18rc1 is
new, while 1.17.6 is current, but 1.18beta1 is old. So, this commit
takes care to sort the entire list properly to avoid that. This way, the
entire list is sorted by version. Nothing changes semantically, as users
of the API can still filter out unstable releases using the "stable:
true" field.

This commit also adds a test case, to make sure this behavior doesn't
regress.

Fixes golang/go#50201.
Fixes golang/go#47367.

Change-Id: Ic136197dcdd47aa149601b75ba5152a2006c790a
Reviewed-on: https://go-review.googlesource.com/c/website/+/371934
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Jason Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Trust: Jamal Carvalho <jamalcarvalho@google.com>
@golang golang locked and limited conversation to collaborators Jan 18, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

3 participants