Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
go.mod missing /v11 at the end of the module directive #1355
Describe the bug
According to https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher, v2 and higher modules go.mod files should include a /vX at the end of the module path in the module directive.
Without this, the version is treated as part of the v0/v1 series by the Go tool. It is not possible to import iris/v11 into a module-aware project without triggering this fallback behavior.
Desktop (please complete the following information):
Importing the module without the version information triggers the backwards-compatibility behavior of the Go tool:
And an entry like this appears on go.mod:
This is not a bug, it's a decision. I know the details of the go modules because I was reading its internal docs and code before even went into the language (go get command) itself but it's a decision to not adopt the path suffix behavior for Iris (and this project is not the only one which is not adopting that one). Users should install following the installation section for specific version and update as normally.
Such a change will bring a ton of breaking changes in existing projects and its users.
About the go get command of specific
@kataras thanks for explaining your rationale.
Unfortunately, the decision seems to go in a different direction than that of Go Modules support in the
With Go 1.13, version validation becomes more strict and here is what I get when I follow the official installation instructions for Iris:
Edit: the behavior changes if iris is in the mod cache. Added a
And with Go 1.12:
Notice that I requested version 11.2.8, and even though the commit hash is correct, the
The same rewrite happens if one uses the alternative method, writing the go.mod file manually:
The workaround for Iris users using Go 1.13 is to use commit hashes instead of (invalid, in Go Module's definition) version numbers:
As an example, to fetch the release v11.2.8:
Not surprisingly, users of other projects are having problems with the stricter version validation and resort to the Go issue tracker, see golang/go#33546 (comment) and subsequent comments.
Reconciling the version number and the