Hacker News Reader

Your users are going to have a bad time if they ever import two different libraries that both depend on different fake "major" versions of your library. The newer of the two will be selected, and any incompatibility that the different libraries are not prepared to handle will break things.

What purpose does that serve?

Unless your version numbers signify something to the user, you might as well just use incremental integers - v1, v2, v3, etc.

This is a comment on an article about Go package management, which enforces that packages a versioned with a semver-esque string.

Your point being?

v1, v2, v3 are not valid module versions in Go, so it requires a slightly different solution.

If you're not distributing your Go package to others as a library, then you don't need to follow the Go module versions. They are only enforced user-side.

True, though if you have code in separate repositories you might want to stick to some versioning scheme to use the module tooling to your advantage.

Why not v0 instead? It's better suited for that purpose.