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

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

Closed
myitcv opened this issue Jul 9, 2018 · 3 comments

Comments

Projects
None yet
5 participants
@myitcv
Copy link
Member

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

This comment has been minimized.

Copy link
Member

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

@rsc

This comment has been minimized.

Copy link
Contributor

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 Jul 17, 2018

@vith

This comment has been minimized.

Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.