fix: include v2 in go module path

[vbrown608]

Ookay so, I failed to consider that in Go, versions after v1 need to have the version included in their module path.

The Go Team suggests achieving this by copying all the v2 code into a v2 subdirectory. I dislike this approach because the most recent version of the module isn't in the repo root. In our case, it would be extra confusing because this repo is also used for Swagger and Js client. That means we would have v2/go, so the most up-to-date go directory would be hidden and the rest of the files in the root would still be about v2 of Swagger and Js. Orrr we could put those under v2 as well, but no one from the JS world is going to expect that.

The Go Team recommends this because the module path is going to match the file structure, so imports without Go modules are still going to work. However, as Go progresses fewer people are using old versions that don't use go modules so will be less of a problem.

The other suggested option is to create a v2 branch. However, we don't really need our v1 code to exist alongside our v2 code - it's very unlikely that we're going to make a fix to v1, we're almost certainly just going to apply it to v2 an expect that users will use that version. And, we're still going to have the problem of making it look good with the Swagger and Js side.

So, I'm taking the third option which is just to append v2 to the end of the module path. If works well and keeps the branching and directory structure clean. Thoughts welcome from others with strong opinions about Go modules, I just formed mine today 😁

The official Go explanation of this situation is hard to scan, I recommend https://donatstudios.com/Go-v2-Modules

[netlify]

Deploy preview for open-api ready!

Built with commit 7a831bb

https://deploy-preview-303--open-api.netlify.app

[keiko713]

memo: this is just from go mod tidy

[keiko713]

I like this option the best too, so looks good to me 👍