Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
cmd/go: go build, list etc can upgrade existing dependency versions #28692
go version devel +644ddaa842 Wed Nov 7 16:12:02 2018 +0000 linux/amd64
It seems that because the listed dependency does not contain the imported package, the go tool is silently upgrading to the latest version. This happens with
Upgrading a dependency is a significant action and should not, I believe, happen as a result of
I'd expect a "package not found" error instead.
changed the title from
cmd/go: go build, test etc can change existing dependencies
cmd/go: go build, test etc can upgrade existing dependency versions
Nov 9, 2018
It's also possible for an arbitrary new dependency to bump up the requirements for existing dependencies.
For example, suppose that
I suppose we could add a special case for “found the package in a newer version of an existing requirement”, but in that case the resolution is clear anyway: the obvious thing to do is to upgrade to some version that contains the package in question, and our default for “some version” is always
Yes, but I don't believe that the
I am still of the opinion that
Preserving the existing version requirement is important because the dependency that leads to a greater required version may only be an internal implementation detail that may change over time. If we later change to a dependency that doesn't require the later version, then it's fine (and desirable) for the minimum version requirement to drop back to the originally stated version.
In general we maintain the invariant that the
The only notion of “time” that Go modules really support is “versions” — even the timestamps of pseudo-versions are converted to fragments of the version string. If some published version of the module has a higher version requirement, there's little reason to go back: the cat is already out of the bag.
On the other hand, if you're just talking about unpublished versions, it's easy enough to recover a minimal change to the
It might be fine? On the other hand, if we've incidentally picked up a fix to some bug and then written some code that depends on that fix, dropping it back out as a side-effect of removing some other package would be very frustrating.
I understand where you're coming from, but I don't think the benefit of minimizing changes outweighs the added subtlety from preserving misleading requirements.
Ah, I'd missed that. That's very interesting (and I think I'm on board with your reasoning there, although I have misgivings because ever-spreading test dependencies could result in a much greater min version requirement than needed) but it doesn't cover this particular case AFAICS.
I honestly think that that special case would be worth having. In this case, the upgrade caused the code to fail (because go/packages hasn't been maintaining backward compatibility) and it was frustrating trying to work out what was going on and why my explicitly stated version requirement was being overridden every time with no indication as to why.
If nothing else, the tool should say explicitly what has happened (in fact I think that it should be shout a little louder every time it adds or changes a dependency in go.mod, but that's probably another issue).
Perhaps we need a