Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
cmd/go: upgrading a module gives different results based on "how" you upgrade #34220
From the Go Wiki:
Therefore, people can upgrade a module by:
Most Go developers I've talked to, including myself, have believed that both options are interchangeable. However, whether a user picks option 1 or option 2 above can actually lead to a different final build list.
While I'm not sure this is a bug, but the fact that how you upgrade a module can lead to different results seems odd or at least something worth documenting.
I have replicated the same dependency tree in the MVS article here: https://research.swtch.com/vgo-mvs
You can find that dependency tree under https://github.com/gomvs
github.com/gomvs/a is the main module and its current commit resides at Algorithm 1:
If we want to trigger Algorithm 3 by upgrading one module (c v1.2.0 to c v1.3.0) we have 2 ways of doing it:
Sort of? It's not “incorrect”, but it is a semantically different operation: editing the
The former resolves inconsistencies by taking the higher version, which potentially discards the edited versions, whereas the latter resolves inconsistencies by downgrading until the requested versions are actually what is selected.
I'm not sure that we should recommend adding duplicate lines as a standard practice. I could imagine a change to the
In my opinion, the most robust option is to always use
I don't think that's mentioned anywhere in the wiki or docs, so should it be? As of recently, I thought the two operations would yield the same exact build list.
In fact the two quotes from the docs/wiki above suggest the two operations are interchangeable.