Ask HN: Go modules and semantic import versioning

2 points by TXV 6 years ago | 1 comment

With the release of Go 1.13, I've recently started digging into Go modules in order to upgrade my code base.

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:

1 About semantic import versioning: https://github.com/golang/go/wiki/Modules#semantic-import-versioning

2 Releasing a v2+ module: https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher

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."

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

The main issue I have with this advice becoming a requirement is that VCS's (VERSION control systems) inherently manage versions. I can prevent you from downloading a backwards-incompatible version of my code just with tags and semver.

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.

I must be missing some major point here. I would love to hear HN's opinion on this.

sethammons 6 years ago |

For a targeted question like this, I'd consider posting to https://www.reddit.com/r/golang/ or 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.