6 ms·

I see a lot of comments in here about the v2+ rule’s reason for existing being to allow importing multiple major versions of a module. That’s not it at all. As

I see a lot of comments in here about the v2+ rule’s reason for existing being to allow importing multiple major versions of a module. That’s not it at all. As the blog post (which was easily Googled by me and explains things quite well IMO) states: “If an old package and a new package have the same import path, the new package must be backwards compatible with the old package.” They’re trying not to break compatibility until a downstream developer explicitly opts in to that breakage. The simplest way to do that is to give the module a new name. And the simplest way to do that is append the major version to the name. Here is the post: https://blog.golang.org/v2-go-modules https://blog.golang.org/v2-go-modules For more background on this principle, I recommend Rich Hickey’s Clojure/conj keynote “Spec-ulation” from 2016: http://blog.ezyang.com/2016/12/thoughts-about-spec-ulation-rich-hickey/ http://blog.ezyang.com/2016/12/thoughts-about-spec-ulation-r...

giancarlostoro 6y ago
I swear I remember reading this somewhere in the Go docs as well but only found it in the FAQ: https://golang.org/doc/faq#get_version https://golang.org/doc/faq#get_version I think this is a reasonable enough approach. You see it in Debian for dependencies so I'm okay with it for Go. It outlines clearly what your dependencies are.
ubertaco 6y ago
That's weird, how then do other languages manage to solve importing packages/modules cleanly without requiring that the name of the package include the version number, while still allowing developers to specify exactly which version of the module they want to use? Surely someone else has solved this problem before, like Rust's Cargo, or Java's Maven, or JS's NPM, or Python's PIP, Ruby's Gems, or... Unlike in every single one of those other languages, this Golang decision means that you can't pin to a specific minor version, or a specific patch version (in the sense of MAJOR.MINOR.PATCH). It's very in-character for the Golang team though: they value simplicity-for-themselves no matter what the complexity-for-you cost is.
- saturn_vk 6y ago
  I'm not aware of maven allowing me to use multiple major-version libraries in the same package.
  - sitkack 6y ago
    You can shade a dependency, which can with the requisite budget in frustration allow for importing a library with multiple versions in the same program. http://maven.apache.org/plugins/maven-shade-plugin/ http://maven.apache.org/plugins/maven-shade-plugin/
- Thaxll 6y ago
  It's short sighted to think that the Go package managment is "simple", there was a lot of thoughts and considerations that was put into it and improvements over other languages ( even recent one like Rust ). Good read: https://research.swtch.com/vgo-principles https://research.swtch.com/vgo-principles which answers some of your questions.
  - stouset 6y ago
    "A lot of thought and consideration" was put into the ten previous approaches they've attempted to solve this problem. I'm starting to think that the reason they've tried so hard to avoid solving interesting problems in the language is that every time they've tried they've made something worse than every other alternative that existed in the problem space.
  - yencabulator 6y ago
    With great effort, sometimes simple solutions are discovered.
- cap10morgan 6y ago
  That's a fair question and something I should have clarified in my comment (though I have a feeling it is likely addressed in the blog post I linked to). It gets into the deeper motivation behind not breaking backwards compatibility within the same-named module. There are two bad extremes here: 1. Never update dependency versions for fear of breakage. This leaves you open to security vulnerabilities (that are easy to exploit because they are often thoroughly documented in the fixed version's changelog / code). And/or you're stuck with other bugs / missing features the upstream maintainer has already addressed. 2. Always just updating all deps to latest and hoping things don't break, maybe running the test suite and doing a "smoke test" build and run if you're lucky. Often a user becomes the first to find a broken corner case that you didn't think to check but they rely on. The approach outlined by Rich Hickey in that Spec-ulation talk I linked to allows you to be (relatively) confident that a package with the same name will always be backwards-compatible and you can track the latest release and find a happy middle ground between those two extremes. Go's approach is one of the few (only?) first-class implementations of this idea in a language's package system (in Clojure, perhaps ironically, this is merely a suggested convention). The Go modules system has its fair share of confusing idiosyncrasies, but this is one of my favorite features of it and I hope they stick to their guns.
grey-area 6y ago
So why can't the module developer choose to change the url if they want to introduce breaking changes? Why is this built into the module system and triggered by a v2? I don't think there is a compelling reason to do so, and there are several compelling reasons not to do so. I think I prefer the status quo where there is very strong pressure to remain backwards compatible if your module is used by a few people. This leads to far less churn in the ecosystem and more stable modules. The article makes the assumption that a major version number is used only for breaking changes, but many software packages use such version numbers for major feature releases (as indeed Go2 seems to plan to when/if they release it). I'm not clear why they should be forced to adopt urls ending in /v2 as well.
- geodel 6y ago
  I guess you are getting in to Go design philosophy. These questions are similar to "why go does not allow lint to just issue warning for unused variables / packages instead of giving hard compiler error?" The answers to these are unfortunately unsatisfactory, no matter how logical. Reasonable thing is to use language which align your philosophy.
  - grey-area 6y ago
    I've used Go for almost a decade and am pretty happy with it, including the rule you mention. It's fine to disagree with decisions made, it may or may not be heeded, but if no-one ever disagrees the language would be poorer for that IMO.
- drvd 6y ago
  A module developer _can_ change the URL if the want to introduce a breaking change. Absolutely no problem here. But they do not _have_ to: Adding the version as v2, v3, ... to the module name works also. Nobody is "forced to adopt urls ending in /v2". Go modules work pretty well, are very flexible but seem to differ too much from what people are used to and nobody really seems to read all the available documentation and descriptions of why that way and not how language X does it.
  - 6y ago

giancarlostoro 6y ago

I swear I remember reading this somewhere in the Go docs as well but only found it in the FAQ: https://golang.org/doc/faq#get_version https://golang.org/doc/faq#get_version I think this is a reasonable enough approach. You see it in Debian for dependencies so I'm okay with it for Go. It outlines clearly what your dependencies are.

ubertaco 6y ago

That's weird, how then do other languages manage to solve importing packages/modules cleanly without requiring that the name of the package include the version number, while still allowing developers to specify exactly which version of the module they want to use? Surely someone else has solved this problem before, like Rust's Cargo, or Java's Maven, or JS's NPM, or Python's PIP, Ruby's Gems, or... Unlike in every single one of those other languages, this Golang decision means that you can't pin to a specific minor version, or a specific patch version (in the sense of MAJOR.MINOR.PATCH). It's very in-character for the Golang team though: they value simplicity-for-themselves no matter what the complexity-for-you cost is.

saturn_vk 6y ago
I'm not aware of maven allowing me to use multiple major-version libraries in the same package.
- sitkack 6y ago
  You can shade a dependency, which can with the requisite budget in frustration allow for importing a library with multiple versions in the same program. http://maven.apache.org/plugins/maven-shade-plugin/ http://maven.apache.org/plugins/maven-shade-plugin/
Thaxll 6y ago
It's short sighted to think that the Go package managment is "simple", there was a lot of thoughts and considerations that was put into it and improvements over other languages ( even recent one like Rust ). Good read: https://research.swtch.com/vgo-principles https://research.swtch.com/vgo-principles which answers some of your questions.
- stouset 6y ago
  "A lot of thought and consideration" was put into the ten previous approaches they've attempted to solve this problem. I'm starting to think that the reason they've tried so hard to avoid solving interesting problems in the language is that every time they've tried they've made something worse than every other alternative that existed in the problem space.
- yencabulator 6y ago
  With great effort, sometimes simple solutions are discovered.
cap10morgan 6y ago
That's a fair question and something I should have clarified in my comment (though I have a feeling it is likely addressed in the blog post I linked to). It gets into the deeper motivation behind not breaking backwards compatibility within the same-named module. There are two bad extremes here: 1. Never update dependency versions for fear of breakage. This leaves you open to security vulnerabilities (that are easy to exploit because they are often thoroughly documented in the fixed version's changelog / code). And/or you're stuck with other bugs / missing features the upstream maintainer has already addressed. 2. Always just updating all deps to latest and hoping things don't break, maybe running the test suite and doing a "smoke test" build and run if you're lucky. Often a user becomes the first to find a broken corner case that you didn't think to check but they rely on. The approach outlined by Rich Hickey in that Spec-ulation talk I linked to allows you to be (relatively) confident that a package with the same name will always be backwards-compatible and you can track the latest release and find a happy middle ground between those two extremes. Go's approach is one of the few (only?) first-class implementations of this idea in a language's package system (in Clojure, perhaps ironically, this is merely a suggested convention). The Go modules system has its fair share of confusing idiosyncrasies, but this is one of my favorite features of it and I hope they stick to their guns.

grey-area 6y ago

So why can't the module developer choose to change the url if they want to introduce breaking changes? Why is this built into the module system and triggered by a v2? I don't think there is a compelling reason to do so, and there are several compelling reasons not to do so. I think I prefer the status quo where there is very strong pressure to remain backwards compatible if your module is used by a few people. This leads to far less churn in the ecosystem and more stable modules. The article makes the assumption that a major version number is used only for breaking changes, but many software packages use such version numbers for major feature releases (as indeed Go2 seems to plan to when/if they release it). I'm not clear why they should be forced to adopt urls ending in /v2 as well.

geodel 6y ago
I guess you are getting in to Go design philosophy. These questions are similar to "why go does not allow lint to just issue warning for unused variables / packages instead of giving hard compiler error?" The answers to these are unfortunately unsatisfactory, no matter how logical. Reasonable thing is to use language which align your philosophy.
- grey-area 6y ago
  I've used Go for almost a decade and am pretty happy with it, including the rule you mention. It's fine to disagree with decisions made, it may or may not be heeded, but if no-one ever disagrees the language would be poorer for that IMO.
drvd 6y ago
A module developer _can_ change the URL if the want to introduce a breaking change. Absolutely no problem here. But they do not _have_ to: Adding the version as v2, v3, ... to the module name works also. Nobody is "forced to adopt urls ending in /v2". Go modules work pretty well, are very flexible but seem to differ too much from what people are used to and nobody really seems to read all the available documentation and descriptions of why that way and not how language X does it.
- 6y ago