@bcmills @jayconrod

Seems reasonable. go get could also write these comments if a particular branch is requested.

Not sure if this will happen for 1.13, given how much other stuff needs to go in, but it would be nice to have.

go.mod does not “pin” dependencies: it specifies minimums.

That said, I think this is a duplicate of #25898. Please reopen if you disagree.

Thanks for the reply. I think that issue is different, but would accomplish the same thing.

But, if you see this thread again, can you briefly explain what you mean by go.mod not pinning dependencies?

I see a line in go.mod like this: k8s.io/apimachinery v0.0.0-20190118094746-1525e4dadd2d and commands like go get foo@e3702bed2 seem to specify an exact revision.

go.mod doesn't pin dependencies, in that the versions specified in your go.mod file are treated as minimum versions — not exact constraints — if and when your module is used as a dependency of some other module.

(If your module is always the main module when you build it, then the “minimum version” is functionally equivalent to “pinning”, but we try not to make that assumption in discussions and documentation.)

Whoa. Does this mean that an upstream dependency can release a new version that will cause my builds to fail? Does go automatically try older versions to see if one works in that case? How would one "pin" an exact upstream version if needed? Is vendoring the only option?

Thanks for the reply!

Does this mean that an upstream dependency can release a new version that will cause my builds to fail?

Nope: the version selected for a given go.mod file is stable over time — it's just not “pinned”, in the sense that if someone else uses your module as a dependency, your module's requirements will set a minimum (but not a maximum) on the versions of modules that they can require in conjunction.

(See https://research.swtch.com/vgo-mvs for details.)

Does go automatically try older versions to see if one works in that case?

The maximum of the minimum-versions explicitly listed in the module graph is always selected. The only time we try a different version is if we see an import statement that names a package that does not exist in the currently-active module versions.

How would one "pin" an exact upstream version if needed?

Generally you don't need to. You set your versions, and because the go command selects the minimum version that satisfies both your explicit requirements and those of your (transitive) dependencies, that selection remains stable over time.