Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

go.mod missing /v11 at the end of the module directive #1355

rhcarvalho opened this issue Sep 4, 2019 · 3 comments


Copy link

commented Sep 4, 2019

Describe the bug

According to, 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.

To Reproduce
Steps to reproduce the behavior:

  1. Run go1.11 get -u


go: go.mod has non-.../v11 module path "" (and .../v11/go.mod does not exist) at revision v11.2.8
go get: error loading module requirements

Expected behavior

go1.11 get -u should download and install the latest version of iris in the v11 series without errors.

Desktop (please complete the following information):

  • OS: any

Additional context

Importing the module without the version information triggers the backwards-compatibility behavior of the Go tool:

go1.11 get -u

And an entry like this appears on go.mod:


require ( v11.1.1+incompatible

This comment has been minimized.

Copy link

commented Sep 7, 2019

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: go1.11 get -u, you should do @master instead as installation section says and you will be fine, it's the same thing.

About the go get command of specific @version, it does not show any error messages here, I will check that later on.

@kataras kataras changed the title [BUG] go.mod missing /v11 at the end of the module directive go.mod missing /v11 at the end of the module directive Sep 7, 2019


This comment has been minimized.

Copy link

commented Sep 7, 2019

@kataras thanks for explaining your rationale.

Unfortunately, the decision seems to go in a different direction than that of Go Modules support in the go tool and semantic versioning assumptions/requirements.

With Go 1.13, version validation becomes more strict and here is what I get when I follow the official installation instructions for Iris:

$ export GO111MODULE=on
$ go1.13 clean -modcache
$ go1.13 version
go version go1.13 linux/amd64
$ go1.13 get
go: finding v11.2.8
go: finding v11.2.8
go get invalid version: module contains a go.mod file, so major version must be compatible: should be v0 or v1, not v11
$ echo $?

Edit: the behavior changes if iris is in the mod cache. Added a go clean -modcache line to show how to reproduce from a clean environment.

The go tool refuses to download/install Iris.

And with Go 1.12:

$ go1.12 mod init
go: creating new go.mod: module
$ go1.12 get
go: finding v11.2.8
$ echo $?
$ grep -F 'kataras/iris' go.mod v0.0.0-20190816162725-d466f8cd92e1 // indirect

Notice that I requested version 11.2.8, and even though the commit hash is correct, the go tool tidies up the version string to v0.

The same rewrite happens if one uses the alternative method, writing the go.mod file manually:

$ cat go.mod

require ( v11.2.8
$ go1.12 get
$ cat go.mod

require v0.0.0-20190816162725-d466f8cd92e1

This comment has been minimized.

Copy link

commented Sep 7, 2019

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:

$ cat go.mod

go 1.13

require ( d466f8cd92e19a766a87d0ab22f2d6269cff5dec
$ go1.13 mod tidy
go: finding d466f8cd92e19a766a87d0ab22f2d6269cff5dec
go: downloading v0.0.0-20190816162725-d466f8cd92e1
go: extracting v0.0.0-20190816162725-d466f8cd92e1
$ grep iris go.mod v0.0.0-20190816162725-d466f8cd92e1

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 go tool expectations may involve releasing a new major version v12, as per the recommended best practice suggested in

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
2 participants
You can’t perform that action at this time.