Middle · Modules and tooling
Version selection and checksums
Why did changing one dependency upgrade another?
Try explaining this aloud before opening the answer. State your assumptions and trace a boundary case.
Reveal a strong answer
Minimal version selection chooses the highest required minimum version of each module in the build list. Adding a dependency can raise a transitive minimum even if your direct requirement did not change.
go.sum authenticates module content hashes; it does not select versions or act as a lockfile. The proxy and checksum database have separate roles, and private module configuration changes where requests are sent.
Inspect go mod graph, go list -m all and go mod why before changing pins. A replace directive changes source selection in the main module/workspace and can mask a compatibility failure that consumers will still see.
Common trap
Forcing an older indirect version cannot satisfy a newer minimum without changing the graph or source.
Try it
A requires C1.2; B requires C1.5. Which C is selected, and what would go.sum decide?
Worked solution
C1.5 is selected by the graph. go.sum verifies the selected module's bytes; it does not choose C1.2 or pin the graph to the first downloaded version. Test the actual selected module list in CI.
Change the constraint
How does a major-version suffix allow v1 and v2 APIs to coexist?
How did you do?
Self-assessment, not a compiler pass or interview score. Explain the reasoning unaided before marking understood.
Not marked. Progress stays on this browser, separate from course completion.
Primary references
Checked 2026-10-20. Use documentation for your pinned runtime, driver and tool version.