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

Jump to bottom

cmd/go: support @latest-prerelease tag #43141

Open
hyangah opened this issue Dec 11, 2020 · 6 comments
Open

cmd/go: support @latest-prerelease tag #43141

hyangah opened this issue Dec 11, 2020 · 6 comments
Labels
FeatureRequest GoCommand cmd/go modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Backlog

Comments

@hyangah
Copy link
Contributor

hyangah commented Dec 11, 2020

From #42545 (comment)

Use case
We have a group of VSCode plugin users who opted in to use prerelease versions of tools. For the users, this will be convenient. Currently the plugin has its own logic to retrieve the list, parse versions, and choose the highest tagged version (including prerelease), but it would be better if this can be done with go command.
@bcmills
Copy link
Contributor

bcmills commented Dec 11, 2020

Compare #42545 (comment).

CC @jayconrod @matloob

@bcmills bcmills added FeatureRequest GoCommand cmd/go modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Dec 11, 2020
@bcmills bcmills added this to the Backlog milestone Dec 11, 2020
@hyangah
Copy link
Contributor Author

hyangah commented Dec 11, 2020

We are definitely in the second group - we want users to test the highest tagged version including prerelease.

@bcmills
Copy link
Contributor

bcmills commented Dec 11, 2020

I don't think I would call it @latest-prerelease, though — that's a bit verbose. Maybe @prerelease?

I also wonder if we should change @v1.x to consider prereleases for v1.x if no release version for that minor is tagged. (Currently we interpret v1.x as ≥v1.x.0, which seems logical but I'm guessing isn't what users actually intend.)

@hyangah
Copy link
Contributor Author

hyangah commented Dec 11, 2020

I am fine with any names. I think we need to be careful when choosing a name commonly used for branch.

No opinion on v1.x - to me that form looks like a shortcut of v1.x.0 (like the Go project itself) and should be considered a stable release.

@gopherbot
Copy link

Change https://golang.org/cl/295418 mentions this issue: src/goInstallTools: use go list to check upgradability

gopherbot pushed a commit to golang/vscode-go that referenced this issue Mar 11, 2021
@hyangah
src/goInstallTools: use go list to check upgradability
a319988 
The extension has been querying the module proxy's /@v/list
endpoint directly to get the list of available gopls version.
This change changes the logic to use `go list -m` to get the
version list. With go1.16, version retraction feature
was added, and using the go command is more reliable way to
learn about the retracted versions. So, use that.

This change also fixes a bug in the tool installation that
prevented Go nightly users from installing gopls prerelease
versions when using 'Go: Update/Install Tools' command.
If the go command supports `@latest-prerelease` tag, it would
have been easier. But that's not available, so we run `go list
-m --versions` and find the last version from Versions.

Updates golang/go#43141

Change-Id: I67fe368cbce734e3b39e5352b3b3f6f08918562c
Reviewed-on: https://go-review.googlesource.com/c/vscode-go/+/295418
Trust: Hyang-Ah Hana Kim <hyangah@gmail.com>
Trust: Rebecca Stambler <rstambler@golang.org>
Trust: Suzy Mueller <suzmue@golang.org>
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
TryBot-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Suzy Mueller <suzmue@golang.org>
@myitcv
Copy link
Member

myitcv commented Apr 15, 2023

I also wonder if we should change @v1.x to consider prereleases for v1.x if no release version for that minor is tagged. (Currently we interpret v1.x as ≥v1.x.0, which seems logical but I'm guessing isn't what users actually intend.)

Quoting this specifically to agree with it. @bcmills this perhaps could have its own issue, independent of decisions taken here regarding @prerelease?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
FeatureRequest GoCommand cmd/go modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Backlog
Development

No branches or pull requests
4 participants
@myitcv @hyangah @bcmills @gopherbot