cmd/go: do not pick obsolete v1 in automatic import selection

[rsc]

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]

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]

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.

[gopherbot]

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