/ go Public
cmd/go: upgrading a module gives different results based on "how" you upgrade #34220
Documentation help wanted modules NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
From the Go Wiki:
go help modules
Therefore, people can upgrade a module by:
go get <mod>@<newVersion>or
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:
go get firstname.lastname@example.org
This will properly implement Algorithm R by adding Module D v1.4.0 to the go.mod file because the Rough List still included email@example.com
Therefore, the upgraded go.mod file will look like this:
If you run
go run .you'll see the following dependency tree being called:
Option 2: Directly edit the go.mod file by going to line 7 in go.mod and simply changing
If a user decided to upgrade from c v1.2.0 to c v1.3.0 by "editing the go.mod file directly" then Algorithm R has no way of remembering that we had c v1.2.0 when running "go build" and therefore we end up downgrading to Module D v1.3.0.
The resulting go.mod file remains the same:
And if you run
go run .you get the following results:
Notice D v1.3.0 (and not D v1.4.0)
The MVS article mentions this behavior as "incorrect" and therefore should we consider directly upgrading the go.mod file incorrect? Also, should we document this behavior?
There is actually option 3, which I didn't know we could do:
Option 3: duplicate modules in go.mod file
You can actually have a go.mod file that looks like this:
cis mentioned twice at two different versions. Running
go mod tidyends up picking the correct version, and also adding
dat v1.4.0 correctly. Given Algorithm R, this makes sense and I wonder if we should also mention it?
The text was updated successfully, but these errors were encountered: