With the release of Go 1.13, I've recently started digging into Go modules in order to upgrade my code base.<p>After a whole day of reading and researching, I'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://github.com/golang/go/wiki/Modules#semantic-import-versioning<p>2 Releasing a v2+ module: https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher<p>Basically they turned a piece of advice into a requirement. I'm talking about the import compatibility rule, summarized by this statement:
"If an old package and a new package have the same import path, the new package must be backwards compatible with the old package."<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://github.com/nicksnyder/go-i18n<p>The main issue I have with this advice becoming a requirement is that VCS'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'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's opinion on this.
For a targeted question like this, I'd consider posting to <a href="https://www.reddit.com/r/golang/" rel="nofollow">https://www.reddit.com/r/golang/</a> or <a href="https://groups.google.com/forum/#!forum/golang-nuts" rel="nofollow">https://groups.google.com/forum/#!forum/golang-nuts</a>.<p>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.<p>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.