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

[rhcarvalho]

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.

To Reproduce
Steps to reproduce the behavior:

1. Run go1.11 get -u github.com/kataras/iris/v11@latest

Output:

go: github.com/kataras/iris/[email protected]: go.mod has non-.../v11 module path "github.com/kataras/iris" (and .../v11/go.mod does not exist) at revision v11.2.8
go get: error loading module requirements

Expected behavior

go1.11 get -u github.com/kataras/iris/v11@latest 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 github.com/kataras/iris@latest

And an entry like this appears on go.mod:

package example.com/my-package

require (
	github.com/kataras/iris v11.1.1+incompatible
)

[kataras]

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 github.com/kataras/iris@latest, 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.

[rhcarvalho]

@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 github.com/kataras/[email protected]
go: finding github.com/kataras/iris v11.2.8
go: finding github.com/kataras/iris v11.2.8
go get github.com/kataras/[email protected]: github.com/kataras/[email protected]: invalid version: module contains a go.mod file, so major version must be compatible: should be v0 or v1, not v11
$ echo $?
1

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 example.com/dummyproject
go: creating new go.mod: module example.com/dummyproject
$ go1.12 get github.com/kataras/[email protected]
go: finding github.com/kataras/iris v11.2.8
....
$ echo $?
0
$ grep -F 'kataras/iris' go.mod
        github.com/kataras/iris 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
module example.com/dummyproject

require (
        github.com/kataras/iris v11.2.8
)
$ go1.12 get
$ cat go.mod
module example.com/dummyproject

require github.com/kataras/iris v0.0.0-20190816162725-d466f8cd92e1

[rhcarvalho]

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
module example.com/dummyproject

go 1.13

require (
        github.com/kataras/iris d466f8cd92e19a766a87d0ab22f2d6269cff5dec
)
$ go1.13 mod tidy
go: finding github.com/kataras/iris d466f8cd92e19a766a87d0ab22f2d6269cff5dec
go: downloading github.com/kataras/iris v0.0.0-20190816162725-d466f8cd92e1
go: extracting github.com/kataras/iris v0.0.0-20190816162725-d466f8cd92e1
...
$ grep iris go.mod
        github.com/kataras/iris 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 https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher.

[kataras]

@rhcarvalho @ywolf @taianrc @pekim Please vote at: #1370