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

invalid version: module contains a go.mod file, so major version must be compatible: should be v0 or v1, not v2 #35732

Closed
diiyw opened this issue Nov 21, 2019 · 19 comments

Comments

@diiyw
Copy link

diiyw commented Nov 21, 2019

What version of Go are you using (go version)?

$ go version
go version go1.13.1 darwin/amd64

Does this issue reproduce with the latest release?

yes

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GO111MODULE="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/xxx/Library/Caches/go-build"
GOENV="/Users/xxx/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/xxx/go"
GOPROXY="direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/xxx/workspace/test/apollo/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/kc/jryd_rpn6_l03ykk8q84d6740000gp/T/go-build000733542=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

go get github.com/zouyx/[email protected]

What did you expect to see?

Correctly download this module.

What did you see instead?

invalid version: module contains a go.mod file, so major version must be compatible: should be v0 or v1, not v2

I import the thirdparty module. The module has the latest version v2.2.1. A project is developing , but go forbid me to get the latest version to continue develop my project,Because the module not compatible with sematic import versioning. Through, I found a way to solve this issue

go get github.com/zouyx/agollo@master

but on go.mod, the version be taged with v1.9.1-0.20191114083447-dde9fc9f35b8 , it is ambiguous . the module not contain version v1.9.1. How i to solve this ?

@bcmills
Copy link
Contributor

bcmills commented Nov 21, 2019

The error message is correct. See https://golang.org/cmd/go/#hdr-Module_compatibility_and_semantic_versioning.

The v1.9.1-0.[…] version string is a pseudo-version generated from the requested commit.

From the perspective of the go command, this is working as designed.

@wrfly
Copy link

wrfly commented Feb 10, 2020

go get github.com/google/[email protected]: github.com/google/[email protected]: 
invalid version: module contains a go.mod file, so major version must be compatible:
should be v0 or v1, not v29

Hi masters, how to solve this? it's under google...

@bcmills
Copy link
Contributor

bcmills commented Feb 10, 2020

@wrfly, use the import path declared in the go.mod file: github.com/google/go-github/v29, not github.com/google/go-github.

@wrfly
Copy link

wrfly commented Feb 11, 2020

Okay, thank you very much, master!

@tj
Copy link

tj commented Mar 6, 2020

yikes, this is not great UX, I hope the Go authors will reconsider some of these choices, or at least improve the error message

@pmalek
Copy link

pmalek commented Mar 31, 2020

So I've been just bitten by this:

require (
	github.com/zeromq/goczmq v4.2.0
)

While: https://github.com/zeromq/goczmq/blob/master/go.mod has

module github.com/zeromq/goczmq/v4

But I still get:

go get -v -u github.com/zeromq/goczmq/v4
go: errors parsing go.mod:
go.mod:9: require github.com/zeromq/goczmq: version "v4.2.0" invalid: module contains a go.mod file, so major version must be compatible: should be v0 or v1, not v4

While:

go: github.com/zeromq/goczmq upgrade => v4.1.0+incompatible

gives me v4.1.0 which is an older release (and marks it as incompatible ? )

@dzrtc
Copy link

dzrtc commented Apr 22, 2020

@bcmills Could you explain again why running go get foo@v7 fails? The reason you gave earlier was technical, but I don't understand why this policy exists. It would be helpful if you could shine some more light on this.

I would expect that go get github.com/foo/foo@v7 would look for a v7 tag or a github.com/foo/foo/v7 path, write the resolved path into my go.mod and download it. That seems reasonable, and it's how other similar tools work (e.g. npm).

A concrete example. I am trying to download github.com/golang-migrate/migrate. They just released version 4.10. Here is the GitHub release link.

Getting the specific version fails.

$ go get -u github.com/golang-migrate/[email protected]
go: finding github.com/golang-migrate/migrate v4.10.0
go: finding github.com/golang-migrate/migrate v4.10.0
go get github.com/golang-migrate/[email protected]: github.com/golang-migrate/[email protected]: invalid version: module contains a go.mod file, so major version must be compatible: should be v0 or v1, not v4

Getting the major version fails

See go.mod.

$ go get -u github.com/golang-migrate/migrate@v4
go get github.com/golang-migrate/migrate@v4: no matching versions for query "v4"

Getting without a version gets the wrong version

$ go get -u github.com/golang-migrate/migrate
$ go clean -i -n github.com/golang-migrate/migrate
cd /Users/dzrtc/go/pkg/mod/github.com/golang-migrate/[email protected]+incompatible

Workaround from the golang-migrate issue tracker

Lots of people are having the same problem. Someone figured out this workaround.

$ go get -tags 'postgres' -u github.com/golang-migrate/migrate/v4/cmd/migrate/
go: finding github.com/golang-migrate/migrate/v4 v4.10.0
go: downloading github.com/golang-migrate/migrate/v4 v4.10.0
go: extracting github.com/golang-migrate/migrate/v4 v4.10.0

Questions

  1. What is the recommended solution for getting v4.10.0 of this package?
  2. Is the @v99 notation still under development? Should we expect it to do anything?
  3. What does incompatible mean in this context?
  4. What does go get -tags do? It appears to be undocumented (go help get | grep "tags" returns nothing)
  5. Is there a way to ask go get to list or report all of the @versions that it sees for a particular target? Is it theoretically possible to write such a feature?

Thanks for helping.

@bcmills
Copy link
Contributor

bcmills commented Apr 22, 2020

@hiromaily
Copy link

+1

@kolaente
Copy link

Also hitting this in go-sqlite3: mattn/go-sqlite3#812

bhelx added a commit to recurly/recurly-client-go that referenced this issue May 20, 2020
golang/go#35732

It looks like our install instructions fall into this [pseudo-version](https://golang.org/cmd/go/#hdr-Pseudo_versions)
trap mentioned in the above issue. This adds the `v3` scope to the url
and it updated the bump script to make sure that the number stays up to
date.
bhelx added a commit to recurly/recurly-client-go that referenced this issue May 20, 2020
golang/go#35732

It looks like our install instructions fall into this [pseudo-version](https://golang.org/cmd/go/#hdr-Pseudo_versions)
trap mentioned in the above issue. This adds the `v3` scope to the url
and it updated the bump script to make sure that the number stays up to
date.
@cncal
Copy link
Contributor

cncal commented May 22, 2020

I wanna use the latest version of github.com/tealeg/xlsx in my project. go get -u github.com/tealeg/xlsx doesn't work and go get github.com/tealeg/[email protected] occurs an error as follows:

require github.com/tealeg/xlsx: version "v3.0.0" invalid: module contains a go.mod file, so major version must be compatible: should be v0 or v1, not v3

Here is my solution:

import "github.com/tealeg/xlsx/v3"

then go mod tidy.
Eventually, go.mod requires the latest version:

require (
      ...
      github.com/tealeg/xlsx v1.0.5
      github.com/tealeg/xlsx/v3 v3.0.0
      ...
)

ctron added a commit to ctron/enmasse that referenced this issue Jun 8, 2020
This is battle between Golang authors and Prometheus authors (probably
some others as well).

Golang requires semantic versioning, and Prometheus doesn't want submit
to those rules:

* With Go 1.13 can no longer flag versions as incompatible, if the have
  a 'go.mod' file in their repository:
golang/go#35732
* Dropping the '+incompatible' suffix is not possible, because the
  module author (Prometheus) would need to add the suffix '/v2'
  to their module. Otherwise you run into:
golang/go#35732 (comment)
* Prometheus doesn't care about Golang's idea of versioning and simply
  ignores it:
prometheus/prometheus#6048 (comment)

You can still put a commit has into the go.mod file as version, but that
gets translated to into a version from the past (for 2.15.2 prometheus
this will resolve into 2.3.x or 1.8.x).

The solution to all of this insanity is, to declare the version you had
in mind in the "requires" section. And then add a mapping entry into
the "replace" section, pointing to the actual version, using a commit
hash and the "v0.0.0" version.
ctron added a commit to ctron/enmasse that referenced this issue Jun 8, 2020
This is battle between Golang authors and Prometheus authors (probably
some others as well).

Golang requires semantic versioning, and Prometheus doesn't want submit
to those rules:

* With Go 1.13 can no longer flag versions as incompatible, if the have
  a 'go.mod' file in their repository:
golang/go#35732
* Dropping the '+incompatible' suffix is not possible, because the
  module author (Prometheus) would need to add the suffix '/v2'
  to their module. Otherwise you run into:
golang/go#35732 (comment)
* Prometheus doesn't care about Golang's idea of versioning and simply
  ignores it:
prometheus/prometheus#6048 (comment)

You can still put a commit has into the go.mod file as version, but that
gets translated to into a version from the past (for 2.15.2 prometheus
this will resolve into 2.3.x or 1.8.x).

The solution to all of this insanity is, to declare the version you had
in mind in the "requires" section. And then add a mapping entry into
the "replace" section, pointing to the actual version, using a commit
hash and the "v0.0.0" version.
ctron added a commit to ctron/enmasse that referenced this issue Jun 8, 2020
This is battle between Golang authors and Prometheus authors (probably
some others as well).

Golang requires semantic versioning, and Prometheus doesn't want submit
to those rules:

* With Go 1.13 can no longer flag versions as incompatible, if the have
  a 'go.mod' file in their repository:
golang/go#35732
* Dropping the '+incompatible' suffix is not possible, because the
  module author (Prometheus) would need to add the suffix '/v2'
  to their module. Otherwise you run into:
golang/go#35732 (comment)
* Prometheus doesn't care about Golang's idea of versioning and simply
  ignores it:
prometheus/prometheus#6048 (comment)

You can still put a commit has into the go.mod file as version, but that
gets translated to into a version from the past (for 2.15.2 prometheus
this will resolve into 2.3.x or 1.8.x).

The solution to all of this insanity is, to declare the version you had
in mind in the "requires" section. And then add a mapping entry into
the "replace" section, pointing to the actual version, using a commit
hash and the "v0.0.0" version.
lulf pushed a commit to EnMasseProject/enmasse that referenced this issue Jun 8, 2020
This is battle between Golang authors and Prometheus authors (probably
some others as well).

Golang requires semantic versioning, and Prometheus doesn't want submit
to those rules:

* With Go 1.13 can no longer flag versions as incompatible, if the have
  a 'go.mod' file in their repository:
golang/go#35732
* Dropping the '+incompatible' suffix is not possible, because the
  module author (Prometheus) would need to add the suffix '/v2'
  to their module. Otherwise you run into:
golang/go#35732 (comment)
* Prometheus doesn't care about Golang's idea of versioning and simply
  ignores it:
prometheus/prometheus#6048 (comment)

You can still put a commit has into the go.mod file as version, but that
gets translated to into a version from the past (for 2.15.2 prometheus
this will resolve into 2.3.x or 1.8.x).

The solution to all of this insanity is, to declare the version you had
in mind in the "requires" section. And then add a mapping entry into
the "replace" section, pointing to the actual version, using a commit
hash and the "v0.0.0" version.
@mrcnski
Copy link

mrcnski commented Sep 4, 2020

Issue should be opened until the error message is made more clear. Users shouldn't have to Google an error message to find out what it means. Take some notes from Rust and cargo.

JoakimSoderberg added a commit to JoakimSoderberg/gobindep that referenced this issue Sep 8, 2020
We are not allowed to remove any trailing version path:

* golang/go#35732

From the official go docs:

* https://golang.org/cmd/go/#hdr-Module_compatibility_and_semantic_versioning

> In semantic versioning, changing the major version number indicates a lack of backwards compatibility with earlier versions. To preserve import compatibility, the go command requires that modules with major version v2 or later use a module path with that major version as the final element. For example, version v2.0.0 of example.com/m must instead use module path example.com/m/v2, and packages in that module would use that path as their import path prefix, as in example.com/m/v2/sub/pkg. Including the major version number in the module path and import paths in this way is called "semantic import versioning". Pseudo-versions for modules with major version v2 and later begin with that major version instead of v0, as in v2.0.0-20180326061214-4fc5987536ef.
@icholy
Copy link

icholy commented Sep 10, 2020

The problem with the error is that it doesn't point the user toward the solution: add major version to import path. This is by no means a good error message, but it contains actionable information.

invalid module path: v2.2.1 expects github.com/zouyx/agollo/v2

@bcmills
Copy link
Contributor

bcmills commented Sep 10, 2020

@icholy and @m-cat, this issue is closed, and the issue as originally reported was a failure to download the module, not the wording of the resulting error message.

That said, we do want to make the errors as clear as possible. If you have a specific improvement to suggest in the phrasing of the error, please open a new issue (or send a change with the proposed improvement)!

zachwhaley added a commit to trendmicro/new-release-version that referenced this issue Oct 29, 2020
Since we are releasing as v2 the module path has to follow this pattern

See:
- golang/go#35732
- https://golang.org/cmd/go/#hdr-Module_compatibility_and_semantic_versioning
@MikkelHJuul

This comment has been minimized.

@kingaj12

This comment has been minimized.

@kingaj12

This comment has been minimized.

@dzrtc

This comment has been minimized.

@bcmills

This comment has been minimized.

@golang golang locked as resolved and limited conversation to collaborators Jan 29, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests