Go vgo: Semantic Versioning and Human Error

Re:Go vgo: Semantic Versioning and Human Error by mfer on Monday May 21, 2018 @03:52PM (#17121266)

go.mod isn't a lock file. It doesn't contain the entire dependency tree the way other lock files do unless you choose to track, at the top level, the entire dependency tree yourself. There aren't tools to prune or update that for changes in the underlying transitive dependencies, either.

It's not a lock and from what I gather from Russ not intended to be.

The solved version doesn't mean it's the right or even a compatible version. This issue here is no maximum version meaning it could solve for an incompatible version due to not having all the information about the complete tree.

[ Parent | on HN ]

Re:Go vgo: Semantic Versioning and Human Error by kardianos on Monday May 21, 2018 @05:21PM (#17121935)

go.mod paired with MVS effectively locks versions into place. It must be computed, but it effectively locks all versions into place for reproducible builds.

> It's not a lock and from what I gather from Russ not intended to be.

go.mod files lock versions into place. If you disagree read the code / design documents. I find it dishonest to say something technically true "It's not a lock [file]" and yet not be true, as it together locks versions in place.

[ Parent | on HN ]

Re:Go vgo: Semantic Versioning and Human Error by mappu on Tuesday May 22, 2018 @02:10AM (#17124033)

> it effectively locks all versions into place for reproducible builds

Assuming git tags don't move.

[ Parent | on HN ]

Re:Go vgo: Semantic Versioning and Human Error by andrewchambers on Tuesday May 22, 2018 @08:54AM (#17125521)

Modverify is optional and detects that.

[ Parent | on HN ]