I’m using a module which symver is now superior to v2. But it seems the default behaviour of of getting the latest release, stops at v1.X.X.
When I try and stipulate which version i’m after using
hugo mod get github.com/theNewDynamicemail@example.com
I’ve got the following error:
invalid version: module contains a go.mod file, so major version must be compatible: should be v0 or v1, not v2
I’m no symver/release/package expert so I’m just wondering what I’m missing and what would be the best practice?
I’ve read this article, but it seems a bit overkill, so maybe there’s something easier out there…
Thanks in advance!
And a bit over a year after your post I stumbled over the same issue
The link you shared was interesting, they want us to put a go.mod into a v2 subfolder. I think that’s quite debilitating in regards to easy updates and releases in those repos (I don’t even start with mono repos).
I thought that the easiest way (see my two links I found) would be to add
/v2 at the end of the module call in go.mod, but that too is very inconsistent and often results in weird
What I did to get this out of the way and out of my mind for now is to violate semver. My versions are now v1.major.minor.patch as in v220.127.116.11. It’s dirty, but to be honest, I think the inventors of this versioning thing are either former theoretical philosophy students that got thrown out and try to abstract the world now in IT or there is some weird hidden deeper meaning. Secret society and such.
Anyway, that won’t help you, but try to stay on v1 and do semver in the 2nd to 4th part is my (hacked) advice.
Here two links that pointed to the v2-solution:
The main lesson is that the path of the module needs to be updated, both in the module’s
go.mod and also when imported into
config.toml, e.g.: “github.com/theNewDynamic/hugo-component-tnd-forms/v2”
This is only for major version changes, and is possibly the most controversial things with Go Modules. That said, it does allow you to import multiple major versions of a module into a project (if that, for some reason, would be needed (I could see some use cases, if you want to build historic versions of your content)).