[S1ngleM4lt]

It’s not too hard to imagine in a larger code base, where maybe libfrontend is relatively stable but libbackend has active development. Now if I want to update libbackend (maybe a new feature was added, maybe there’s been a critical bug fix) I shouldn’t have to wait for the libfrontend maintainers to update their dependencies, sort out any breaking changes, and verify there were no regressions to do so.

Prior to go modules this was even worse with third party packages. I’ve had cases where my app has integrations with a few google services like maps, sheets, and text-to-speech. It turns out the libraries for all of these services, understandably, also have certain dependencies in common. If you run in to the unfortunate situation where you need to update one of the google libraries, and that updated library now relies on an updated version of a dependency required by others, you’ll end up needing to update all of the other libraries. Granted it’s usually a good idea to update, but it turns a theoretical 1 hour task (update library to use new feature) in to a headache that might take several days depending on how big the changes were to the other libraries

[tsimionescu]

> Granted it’s usually a good idea to update, but it turns a theoretical 1 hour task (update library to use new feature) in to a headache that might take several days depending on how big the changes were to the other libraries

Well, you will anyway have to spend a few days, often. You either spend it taking a new version of several libraries, or you spend it digging through bizarre issues because your upgrade of maps broke your integration with sheets, since your older sheets was never tested with the newer shared library version and has a bug.