4 ms·

I enjoy Go’s approach. This is a cultural thing more than a function of what the language itself imposes (and there are certainly many exceptions), but usually

I enjoy Go’s approach. This is a cultural thing more than a function of what the language itself imposes (and there are certainly many exceptions), but usually major version = revolutionary change (might as well be a new library). Major versions are taken as opportunities to refine what is known about the problem space and fix bad abstractions. Maybe a remmenant from the pre-module days.

jrockway 5y ago
Yeah, Go's approach seems to be doing fairly well in practice. There are occasional problems (logrus's author changing the capitalization of their name, azure-autorest), but overall it seems to work. One thing that's nice is that library changes are scoped to a top-level module. So if you have two projects and update a module that both projects use in one of your projects, you don't update the libraries used by the other project. And, fresh installs pick the exact version the go.mod file specifies; version substitution logic only shows up when you depend on module A and module B that both depend on module C and A and B specify a different minor version of C. This is as annoying as it is in Python or Node, but at least more limited in scope. (A project I work on suffered greatly with this problem. We depended on Kubernetes, and had a tiny bit of code that reads logs from Loki. Loki's client depends on Prometheus, which depends on Kubernetes. So the version of Kubernetes we could use was limited by that selection, and we had no control beyond forking the Loki library. If you're a module author and want to avoid inflicting this pain upon your users; a couple things went wrong here. A long time ago Kubernetes' client-go used go module versions matching the public version of Kubernetes. 10 corresponded with 1.10, 11 corresponded with 1.11, etc. Go doesn't consider these two compatible, but they basically are. They switched the version numbers to be 0.10, 0.11, etc. resolving that problem. Our dependency on Loki was for the 1.x branch, which was too old to benefit from this. The other thing authors can do is not bundle their clients and servers. It's convenient, since your tests probably like using the client to talk to the server. But if you can break that dependency, then you probably only have a dependency on net/http and not all of Kubernetes, which is nice for your clients. Oh well!)
- travisd 5y ago
  I’ve had to fork a dependency (Kaniko). That wasn’t the main reason at the time, but it did end up helping that (since kaniko depends on a specific docker version). But at the very least, forking is relatively easy (git subtree plus replace in go.mod).

jrockway 5y ago

Yeah, Go's approach seems to be doing fairly well in practice. There are occasional problems (logrus's author changing the capitalization of their name, azure-autorest), but overall it seems to work. One thing that's nice is that library changes are scoped to a top-level module. So if you have two projects and update a module that both projects use in one of your projects, you don't update the libraries used by the other project. And, fresh installs pick the exact version the go.mod file specifies; version substitution logic only shows up when you depend on module A and module B that both depend on module C and A and B specify a different minor version of C. This is as annoying as it is in Python or Node, but at least more limited in scope. (A project I work on suffered greatly with this problem. We depended on Kubernetes, and had a tiny bit of code that reads logs from Loki. Loki's client depends on Prometheus, which depends on Kubernetes. So the version of Kubernetes we could use was limited by that selection, and we had no control beyond forking the Loki library. If you're a module author and want to avoid inflicting this pain upon your users; a couple things went wrong here. A long time ago Kubernetes' client-go used go module versions matching the public version of Kubernetes. 10 corresponded with 1.10, 11 corresponded with 1.11, etc. Go doesn't consider these two compatible, but they basically are. They switched the version numbers to be 0.10, 0.11, etc. resolving that problem. Our dependency on Loki was for the 1.x branch, which was too old to benefit from this. The other thing authors can do is not bundle their clients and servers. It's convenient, since your tests probably like using the client to talk to the server. But if you can break that dependency, then you probably only have a dependency on net/http and not all of Kubernetes, which is nice for your clients. Oh well!)

travisd 5y ago
I’ve had to fork a dependency (Kaniko). That wasn’t the main reason at the time, but it did end up helping that (since kaniko depends on a specific docker version). But at the very least, forking is relatively easy (git subtree plus replace in go.mod).