The Official Go Modules Documentation

github.com

No other programming language has cost me that much time, figuring out vendoring for a few dependencies.

The v2 story is just broken. It is nice to have a possibility to have multiple versions of the same package in this 0.1% of projects. The cost of it is anguish and frustration for 99.9%.

On the other hand I am seeing libraries teetering on the border of introducing breaking changes to point releases, or holding back progress, just to avoid going v2.

Nonsense

+incompatible

What if, instead of having v1 > v2 incompatible changes, you create a new library with the new api interface, rather than just upgrading a version. If you want to change the implementation details, have a second library that you use in both of them, but if the name of the library remains the same, the api interface would never break. Would make people more conservative with breaking the api interface, but not at all holding back progress.

Just stay in 0.X.X

Reply on news.ycombinator.com