
Ask HN: Go modules and semantic import versioning - TXV
With the release of Go 1.13, I&#x27;ve recently started digging into Go modules in order to upgrade my code base.<p>After a whole day of reading and researching, I&#x27;m still baffled by some of the features.
In particular, I find problematic the combination of these two pieces of docs:<p>1 About semantic import versioning: https:&#x2F;&#x2F;github.com&#x2F;golang&#x2F;go&#x2F;wiki&#x2F;Modules#semantic-import-versioning<p>2 Releasing a v2+ module: https:&#x2F;&#x2F;github.com&#x2F;golang&#x2F;go&#x2F;wiki&#x2F;Modules#releasing-modules-v2-or-higher<p>Basically they turned a piece of advice into a requirement. I&#x27;m talking about the import compatibility rule, summarized by this statement:
&quot;If an old package and a new package have the same import path, the new package must be backwards compatible with the old package.&quot;<p>This mostly results in having to maintain either separate branches, or even same-branch separate sub-directories containing the major version code. Example: https:&#x2F;&#x2F;github.com&#x2F;nicksnyder&#x2F;go-i18n<p>The main issue I have with this advice becoming a requirement is that VCS&#x27;s (VERSION control systems) <i>inherently</i> manage versions. I can prevent you from downloading a backwards-incompatible version of my code just with tags and semver.<p>I understand that import versioning might help solve the problem of diamond imports, but I don&#x27;t see why the solution must be a toolchain-level VCS that overlaps with my repository VCS.<p>I must be missing some major point here. I would love to hear HN&#x27;s opinion on this.
======
sethammons
For a targeted question like this, I'd consider posting to
[https://www.reddit.com/r/golang/](https://www.reddit.com/r/golang/) or
[https://groups.google.com/forum/#!forum/golang-
nuts](https://groups.google.com/forum/#!forum/golang-nuts).

Go packages have tried to be backwards compatible in general since the
beginning; it is part of the culture following the Go compatibility promise.
Developers have been free to ignore this.

The idea is fairly straight forward: as you update your packages, they should
be backwards compatible. If it is not, you should make a new major version,
and this is typically done with a new subdirectory/package (like a /v2).
Nothing more to it than that.

