3 ms·
I just keep all my go project major versions at 1, then use the second number as "major" and the third number as "minor". Anything incompatible increments major
by kstenerud 5y ago
I just keep all my go project major versions at 1, then use the second number as "major" and the third number as "minor". Anything incompatible increments major, anything compatible increments minor.
This avoids all that v2, v3, v4 "nanny knows best" nonsense.
- maxmcd 5y agoYour 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.
- paskozdilar 5y agoWhat 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.
- pgwhalen 5y agoThis is a comment on an article about Go package management, which enforces that packages a versioned with a semver-esque string.
- paskozdilar 5y agoYour point being?
- pgwhalen 5y agov1, v2, v3 are not valid module versions in Go, so it requires a slightly different solution.
- paskozdilar 5y agoIf 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.
- pgwhalen 5y agoTrue, 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.
- mfcl 5y agoWhy not v0 instead? It's better suited for that purpose.