Go’s Major Versioning Sucks – From a Fanboy
I&#x27;m the author of the <i>other</i> recent post that made it to the front page about the trouble with Go&#x27;s v2+ modules.<p>I disagree with much of this post.<p>&gt; Go makes updating major versions so cumbersome that in the majority of cases, we have opted to just increment minor versions when we should increment major versions.<p>I disagree with this, wholeheartedly. I think Go&#x27;s module system making modules separate packages on major versions is actually <i>great</i> once you actually know how it works. The problem is simply that it&#x27;s non-obvious and not well understood. I think they could have made it more obvious requiring in on v1 for starters.<p>Beyond that you should absolutely be tagging major versions for every breaking change, and it <i>should</i> be something a developer has to stop and think about. Not something to be taken lightly, EVEN with regard to internal libraries.<p>You can learn how to code things preemptively so they are flexible for additive changes and require fewer breaking changes. It&#x27;s almost always worth the effort in the long run.<p>To my posts point, the problem is just <i>people don&#x27;t</i> know how it works, and it&#x27;s design makes it something you learn late into a project, when you&#x27;re tagging v2, rather than something you hit early.<p>FWIW, my post for anyone didn&#x27;t catch it:<p><a href="https:&#x2F;&#x2F;donatstudios.com&#x2F;Go-v2-Modules" rel="nofollow">https:&#x2F;&#x2F;donatstudios.com&#x2F;Go-v2-Modules</a>