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: version resolution with explicit commits can result in older versions #32182

Closed
rogpeppe opened this issue May 22, 2019 · 2 comments
Closed
Labels

Comments

@rogpeppe
Copy link
Contributor

@rogpeppe rogpeppe commented May 22, 2019

What version of Go are you using (go version)?

$ go version
go version devel +ab724d43ef Mon May 20 20:58:14 2019 +0000 linux/amd64

When migrating a large code base to using modules, it's important that nothing break. Of course, the main guard against that should be tests, but also it would be good if go mod init could be relied upon to do as good a job as it can when converting from old VCS systems.

I am converting a fairly large set of top level modules to using modules (mostly from glide), and I have observed that it's not uncommon for the finally resolved version of a module to be older from the previously locked version.

As I understand it, with MVS, the version of a dependency could get newer, but it should be highly unlikely to get older (and even it does get older by date, the commit of the new dependency should not be a direct ancestor of the old one).

I tested this as follows: for each top level module, I created a new go.mod file with directly specified commits taken from the glide.lock file (I didn't use go mod init because of issue #32161). I ran go mod tidy. Then I used go list -m all and, for each listed dependency that was also in the glide.lock file, I resolved the module version to its git commit. I compared the dates of the two commits, and collected the set of modules where the new commit was older than the new one.

Over 68 modules, 4 had completely unchanged versions, 20 had versions that had moved forward, and 44 had some regressions in version. Note that all the regressions were true regressions - that is, the new dependency was an ancestor of the original dependency in all cases.

I will continue to investigate this and report specific reproducible cases here when I find them.

In case it helps, the (quickly hacked) code that I used to check the commit versions is here.

@rogpeppe rogpeppe added the modules label May 22, 2019
@rogpeppe

This comment has been minimized.

Copy link
Contributor Author

@rogpeppe rogpeppe commented May 22, 2019

@rogpeppe

This comment has been minimized.

Copy link
Contributor Author

@rogpeppe rogpeppe commented May 22, 2019

Actually, this issue is almost certainly just a duplicate of #27171. I'll close it for now until/unless I find a problem that isn't that one.

@rogpeppe rogpeppe closed this May 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.