Skip to content

cmd/go: ability to list available major versions of a module #26286

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.

Sign up for GitHub

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
Closed
myitcv opened this issue Jul 9, 2018 · 5 comments
Closed

cmd/go: ability to list available major versions of a module #26286

myitcv opened this issue Jul 9, 2018 · 5 comments
Labels
FrozenDueToAge modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Go1.11

Comments

@myitcv
Copy link
Member

myitcv commented Jul 9, 2018

Picking up discussion from https://go-review.googlesource.com/c/vgo/+/122075#message-2f083e869e098fd047f0f846690e3c0b8c9dd191:

What's the workflow where you think that kind of more general query will be important?

There are two that I've come across so far:

  • converting a "project" to be vgo-aware, where a dependency imported as, for example, example.com/blah, happens to be v >= 2. If you're converting a project that does not have a well known dependency manager file that tells vgo the dependency version is, say, 2.4.0, then you need to discover the latest major version (because that's almost certainly what you want) in order to either adjust import paths or vgo get ...@vX
  • similarly, the other day I wanted to use mvdan.cc/sh/syntax. Now arguably I'm still thinking in terms of "old" Go import paths. No doubt we'll need to add something to godoc.org to list major versions etc, but until we get there I needed to see what major versions were available in order that I could choose the latest. (I think we can ignore the fact that mvdan.cc/sh/syntax has itself not been converted to be vgo-aware).

In both cases, especially for custom import paths, this involves a couple of lookups via curl, github etc. Not impossible, but if we had this as part of the vgo command that would help.

/cc @rsc @bcmills
@gopherbot gopherbot added this to the vgo milestone Jul 9, 2018
@bcmills
Copy link
Contributor

bcmills commented Jul 9, 2018

There is a more general case of the “converting a project” use-case: it is very similar to “upgrading a project to a new major version”.

At some point we may want some sort of mode (go get -u=major or go fix -m?) that forcibly upgrades imports of a module to a newer major version — for example, by inlining functions in the old version that wrap calls to the new version, or forcibly updating import paths without ensuring that the resulting code actually compiles, or perhaps some other means.

We probably shouldn't actually implement that mode at this point in time, but we can at least consider how list -m -versions might interact with it. (If there is a list behavior that harmonizes well with all reasonable “forcible upgrade” designs, we could go ahead and implement at least the list part.)

@rsc rsc modified the milestones: vgo, Go1.11 Jul 12, 2018
@rsc rsc added the modules label Jul 12, 2018
@rsc rsc changed the title x/vgo: ability to list available major versions of a module cmd/go: ability to list available major versions of a module Jul 12, 2018
@bcmills bcmills added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jul 13, 2018
@bcmills bcmills mentioned this issue Jul 16, 2018
Closed
@rsc
Copy link
Contributor

rsc commented Jul 17, 2018

For legacy concerns this is a duplicate of #26238, and the fix for that issue will start showing legacy v2 v3 etc as if they were "versions" of v1.

For non-legacy concerns (you're using x and want to find out that x/v2 exists) I think that's beyond the scope of the go command.

So closing as duplicate / out of scope.

@rsc rsc closed this as completed Jul 17, 2018
@vith
Copy link

vith commented Apr 30, 2019

For non-legacy concerns (you're using x and want to find out that x/v2 exists) I think that's beyond the scope of the go command.

I hope this will be reconsidered. I think major versions being developed and maintained as if they are separate projects is the exception, not the rule.

It wouldn't surprise me if hiding the availability of new major versions from developers who are querying for out of date dependencies contributes to a hesitance to bump major versions at all, even when semver semantics demands it.

@R-omk
Copy link

R-omk commented Mar 6, 2020

@bcmills
So what about the ability to view possible major versions via go list -u -m -versions command?
This would help a lot in finding versions for a variety of testing and building automation tools and
this method looks much more preferable than manual tag parsing in a VCS.

@bcmills
Copy link
Contributor

bcmills commented Mar 6, 2020

@R-omk, note that this issue is closed, and we do not normally track closed issues.

Since different major versions have different import paths (and, presumably, incompatible APIs), it does not seem feasible in general to build automation tools that can upgrade across major versions without additional metadata.

(But see #32816 for a related proposal for additional metadata.)

@golang golang locked and limited conversation to collaborators Mar 6, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Go1.11
Development

No branches or pull requests
6 participants
@rsc @R-omk @vith @myitcv @bcmills @gopherbot