Installing a go module fails with `invalid: module contains a go.mod file, so major version must be compatible`

Question

I'm trying to import from Jenkins-X/jx to customize some stuff a little bit.

I'm really new to go heads up

but trying to go get./... fails.

my go.mod file

module github.com/my-org/my-project

go 1.13

require github.com/jenkins-x/jx v2.0.383

I get

... require github.com/jenkins-x/jx: version "v2.0.383" invalid: module contains a go.mod file, so major version must be compatible: should be v0 or v1, not v2

which is because jx has a few requirements in its mod file

But I'm not sure what I have to do to actually download the module.

Answer 1

To anyone looking to compile with some neat Jenkins-x functions I was able to talk to the creators and found out a few things.

1. Go 1.12.4
2. Look at their lighthouse project which has a go.mod and uses jenkins-x/jx as a requirement
3. As mentioned in the comments once a project goes above major version 1 essentially go.mod uses 0.0.0-timestamp-commithash

Answer 2

This error happens when you attempt to fetch a module that has a major version equal or higher than v2 , but either their own go.mod file, or your import path are missing the necessary /vN suffix.

This is based on semantic import paths :

If the module is version v2 or higher, the major version of the module must be included as a /vN at the end of the module paths used in go.mod files

Using your example, this command fails with the error in your question:

go get github.com/jenkins-x/jx@v2.0.383

If you require v2.xx , then you must fetch the module as (note the /v2 at the end before @ ):

go get github.com/jenkins-x/jx/v2@v2.0.383

However the go.mod file of jenkins-x/jx project at v2.0.383 version declares the module path as module github.com/jenkins-x/jx , so you still can't fetch it with the /v2 suffix, because they don't declare it like that. It will fail with:

github.com/jenkins-x/jx/v2@v2.0.383: go.mod has non-.../v2 module path "github.com/jenkins-x/jx" (and.../v2/go.mod does not exist) at revision v2.0.383

This was fixed in a later version. You can run go get github.com/jenkins-x/jx/v2@latest which will resolve to v2.1.155 .

As you can see, this issue may not be your fault. In that case you can only ask the repository maintainers to fix their go.mod and comply with semantic versioning.

Alternatively you can clone the repo locally and use a replace directive, but that will work only, in fact, locally.

---

Note: if the project is v2 or higher and it does not have a go.mod file, it will result in a dependency with +incompatible

Answer 3

In go a major version bump must ensure that the import path is different from other major version. The v1 version doesn't need any suffix, all following major version bump must have the major version suffix in the module name. In your case that should be:

require github.com/jenkins-x/jx/v2 v2.0.383

The import path used then in your go source files should also specify that. You can have more information about this convention here https://github.com/golang/go/wiki/Modules#why-must-major-version-numbers-appear-in-import-paths

But some module authors don't follow this rule and this is incompatible with what is expected from the go tool. If you have write access to the module, you should fix the module name so that the major version appears in the module definition.

For this specific package none of the major versions add the required suffix on the module name. I guess as it is a CLI tool, it is not supposed to be consumed by other modules. Anyway if you need to import that, you have a workaround by specifiying the commit id corresponding to the label you want to depend on:

go get github.com/jenkins-x/jx@c71c08508888ec

But you can expect to have other problem then because this module doesn't seem to expect to be consume from other module.

And you will be also on your own to upgrade this package, the go tool won't be able to bump the version itself as it doesn't know the current one.