Closed tooolbox closed 4 years ago
To support Modules and GOPATH, it seems like the subdirectory technique is the best:
The recommended strategy is to develop v2+ modules in a directory named after the major version suffix.
This approach is compatible with tools that aren't aware of modules: file paths within the repository match the paths expected by go get in GOPATH mode. This strategy also allows all major versions to be developed together in different directories.
Other strategies may keep major versions on separate branches. However, if v2+ source code is on the repository's default branch (usually master), tools that are not version-aware — including the go command in GOPATH mode — may not distinguish between major versions.
Seems like this was rolled back to v1.7.0
I saw v2 was released which is great!
One note, I'm pretty sure that it will break Go Modules unless you increment the paths involved. Here's a blog post from the Go team on it: https://blog.golang.org/v2-go-modules
Relevant snippet:
So this would involve adding
/v2
to the module declaration ingo.mod
, as well as to all of the "internal" import paths in the project. If you like, I can take a stab at it and do a PR.I'm also not sure how much you are still supporting the GOPATH paradigm, because if that's a concern then I think more research is in order to be sure that both are handled correctly—it's difficult but doable, from what I understand.