Re:Go vgo: Semantic Versioning and Human Error
by dbaupp on Monday May 21, 2018 @10:14PM
(#17123309)
Many package managers interpret semver in a similarly mechanical way, e.g. npm, bundler, cargo (and, I think, elm-package, and I'm sure others too), but they choose different versions based on that information.
And crucially, in these systems you are given an escape hatch (declaring versions that are not ok), which vgo does not support.
Re:Go vgo: Semantic Versioning and Human Error
by hectormalot on Tuesday May 22, 2018 @06:15AM
(#17124880)
I think vgo allows you exclude specific versions in go.mod. It only works for specific versions, not ranges though
There are exclusions, but they are only available for the current module:
> Exclusions only apply to builds of the current module. If the current module were required by a larger build, the exclusions would not apply.
Re:Go vgo: Semantic Versioning and Human Error
by cdoxsey on Monday May 21, 2018 @10:10PM
(#17123301)
Sure they do. What if I do want to share the same struct between packages? I need both of my dependencies to share the same version of their dependant packages.
I don't think I understand what you're getting at. In ruby I can say I depend on a version > 1.2.0 and some other project could use my package and use version 1.2.1, thus altering my dependency. Bundler lets me do that because it makes assumptions about what version numbers mean.
The lock file makes sure this only changes when I want it too, but semver is an integral part of the system
That vgo encodes semver as sone sort of contract system is crazy pants on a whole new level.