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: do not pick obsolete v1 in automatic import selection #26238

Closed
rsc opened this issue Jul 6, 2018 · 3 comments

Comments

Projects
None yet
4 participants
@rsc
Copy link
Contributor

commented Jul 6, 2018

It's not OK that vgo selects the latest v1 when there is a v2 or later not written using semantic import versioning that has replaced the v1. Typically such an import is expecting the latest tag, not the last v1 (or v0).

Examples include github.com/coreos/etcd and k8s.io/client-go.

@marwan-at-work

This comment has been minimized.

Copy link
Contributor

commented Jul 10, 2018

Is there a proposed solution for this already?

If not, what if vgo looks at the latest tag, and takes the commit the latest tag is at and then writes a replace rule for it?

something like replace github.com/coreos/etcd v2.1.1 => github.com/coreos/etcd v0.0.0-time-shaOf2.1.1

@bcmills

This comment has been minimized.

Copy link
Member

commented Jul 11, 2018

The tricky part is how to detect when a major version switches from non-semantic import paths to semantic ones: if the repository is tagged v3.3.8 without a go.mod, but adds a tag v3.4.0 with a go.mod declaring module github.com/coreos/etcd/v3, then we would want to start enforcing the /v3 import path as of v3.4.0 (and stop the “latest” for the unversioned track at v3.3.8).

But the key insight, I think, is that if the unversioned import path ever meant v3, it should continue to mean v3 forever. That's the point of semantic import versioning, after all: the compatibility of an import path should not change over time, and even if we (accidentally or intentionally) broke path compatibility once that's no reason to do it again. So it should suffice to check the first commit tagged at each major version: the last major version that lacks a go.mod file at the first commit is, de facto, the major version for the unversioned import path, and if a go.mod file is added for that major version it should continue to use that import path.

There is no reason to change the import path at that point, because the damage is already done. In fact, changing to a versioned import path would imply that there is no longer a single canonical import path for that package. The package maintainers are free to bump the major version again when they're ready to switch to a semantic import path, but we shouldn't try to push them to a new path when it doesn't break compatibility with up-to-date existing code.

@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: do not pick obsolete v1 in automatic import selection cmd/go: do not pick obsolete v1 in automatic import selection Jul 12, 2018

@gopherbot

This comment has been minimized.

Copy link

commented Jul 17, 2018

Change https://golang.org/cl/124384 mentions this issue: cmd/go/internal/module: add new +incompatible version build annotation

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.