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

cmd/go: major version without preceding tag must be v0, not v1 - breaks build of github.com/go-check #33546

Closed
tamalsaha opened this issue Aug 8, 2019 · 10 comments
Labels
FrozenDueToAge modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@tamalsaha
Copy link

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

$ go version

go version devel +e9782bdebd Thu Aug 8 00:38:10 2019 +0000 linux/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="auto"
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/travis/.cache/go-build"
GOENV="/home/travis/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/travis/gopath"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/travis/.gimme/versions/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/travis/.gimme/versions/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/travis/gopath/src/gomodules.xyz/cert/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 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build463038650=/tmp/go-build -gno-record-gcc-switches"

What did you do?

I am running my tests against go:tip in Travis. This is breaking build for external library.
https://travis-ci.org/gomodules/cert/jobs/569425585

What did you expect to see?

I expect the build to not break. This can be a warning not an error.

What did you see instead?

$ go build ./...
go: github.com/appscode/[email protected] requires
github.com/flosch/[email protected] requires
github.com/go-check/[email protected]: invalid pseudo-version: major version without preceding tag must be v0, not v1

@ianlancetaylor
Copy link
Member

CC @bcmills @jayconrod

Are you suggesting that we should remove that check, or are you suggesting that github.com/go-check should fix their versioning?

@tamalsaha
Copy link
Author

I am suggesting that Go should remove that check or make that a warning. I am sure there are more libraries that are out there which don't follow this rule.

@ianlancetaylor ianlancetaylor changed the title major version without preceding tag must be v0, not v1 - breaks build cmd/go: major version without preceding tag must be v0, not v1 - breaks build of github.com/go-check Aug 8, 2019
@ianlancetaylor ianlancetaylor added modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Aug 8, 2019
@ianlancetaylor ianlancetaylor added this to the Go1.14 milestone Aug 8, 2019
@tamalsaha
Copy link
Author

Here is another but seems related build break:

https://travis-ci.org/kmodules/monitoring-agent-api/jobs/569397065#L231

go: kmodules.xyz/[email protected] requires
	github.com/Azure/go-autorest/[email protected] requires
	github.com/Azure/go-autorest/[email protected] requires
	contrib.go.opencensus.io/exporter/[email protected] requires
	github.com/census-instrumentation/[email protected]: invalid pseudo-version: version before v0.1.0 would have negative patch number
The command "go build -v ./..." exited with 1.

@jayconrod
Copy link
Contributor

Sorry, this change is intentional. In Go 1.13, the Go command enforces pseudo-version validity more strictly. Among other reasons, this is necessary to prevent people from bypassing minimal version selection by using pseudo-versions like v1.999.999-20180628173108-788fd7840127. It's important that versions are under control of module authors. The change is explained in the Go 1.13 release notes.

If an invalid version appears in a go.mod file you control, you can replace it with a commit or branch name. For example, change

require github.com/go-check/check v1.0.0-20180628173108-788fd7840127

to

require github.com/go-check/check 788fd7840127

then run go mod tidy, which will update the go.mod with the equivalent pseudo-version.

If an invalid version appears in one of your dependencies (as is the case here), you can work around it with a replace directive:

replace github.com/go-check/check v1.0.0-20180628173108-788fd7840127 => 788fd7840127

then run go mod tidy.

@bcmills
Copy link
Contributor

bcmills commented Aug 8, 2019

Note that these issues have already been fixed in their respective upstream repositories:
flosch/pongo2@bbf5a6c
census-ecosystem/opencensus-go-exporter-ocagent@472362a

It may require a bit of work to upgrade past the references to the invalid versions, but it should be possible — and you can patch them with replace directives in the meantime.

@tamalsaha
Copy link
Author

If an invalid version appears in a go.mod file you control, you can replace it with a commit or branch name.

What do you mean by invalid version? I am using Go 1.12.7 on my development machine. This is how I got that version number. I add the following line:

require (
  github.com/go-check/check <commit_hash>
)

Then run go mod tidy. Go automatically writes that invalid version. So, what was auto generated by Go 1.12.7 is now considered invalid by Go 1.13?

Also, the original issue major version without preceding tag must be v0, not v1 seems unrelated in that case. What to do about that?

@bcmills
Copy link
Contributor

bcmills commented Aug 8, 2019

What do you mean by invalid version?

See https://tip.golang.org/doc/go1.13#version-validation.

I am using Go 1.12.7 on my development machine. […] Go automatically writes that invalid version.

If you already had an invalid version in your module cache with Go 1.12, then it would erroneously use that version to satisfy new dependencies in other modules too. See #27171 and #27173.

Also, the original issue major version without preceding tag must be v0, not v1 seems unrelated in that case.

That is one of the many sub-cases of #27173. The replace workaround should work for that version as well.

@rhcarvalho
Copy link
Contributor

@tamalsaha in the particular case of the Go code found in https://github.com/go-check/check, the canonical package import is gopkg.in/check.v1. If you use that import path with Go 1.13 (or any previous release), you should have no errors:

$ go1.13 get gopkg.in/check.v1
go: finding gopkg.in/check.v1 latest
go: downloading gopkg.in/check.v1 v1.0.0-20190902080502-41f04d3bba15
go: extracting gopkg.in/check.v1 v1.0.0-20190902080502-41f04d3bba15
go: downloading github.com/kr/pretty v0.1.0
go: extracting github.com/kr/pretty v0.1.0
go: downloading github.com/kr/text v0.1.0
go: extracting github.com/kr/text v0.1.0
go: finding github.com/kr/pretty v0.1.0
go: finding github.com/kr/text v0.1.0

kpurdon added a commit to kpurdon/venona that referenced this issue Sep 12, 2019
golang/go#33546

go: contrib.go.opencensus.io/exporter/[email protected] requires
	github.com/census-instrumentation/[email protected]:
        invalid pseudo-version: version before v0.1.0 would have
        negative patch number
@philippgille
Copy link

If you already had an invalid version in your module cache with Go 1.12, then it would erroneously use that version to satisfy new dependencies in other modules too.

I've got a repo with lots of modules and dependencies between those modules. I've also got a commit in the remote repo where versions in the go.mod file have an invalid pseudo version, which I only realized by trying to build all modules with Go 1.13 in addition to 1.12.7. I'm now trying to fix this. I deleted the local cached module, searched&replaced the invalid version string by the newest commit hash and ran go mod tidy on all modules. Some entries in the go.mod files are correct now, while others still get an invalid pseudo version, despite having deleted the cached modules.

I guess a replace could work (as in so many cases where people reported problems with submodules or invalid pseudo versions), but I just wanted to point out that deleting the module cache doesn't seem to solve the issue in all cases.

If this is unexpected behavior I can provide more details. If this is expected behavior then maybe a clarification helps me and future GitHub issue readers to understand it better.

go version go1.12.7 windows/amd64

AkihiroSuda added a commit to AkihiroSuda/buildkit_poc that referenced this issue Oct 14, 2019
golang/go#33546 (comment)

Also update tonistiigi/fsutil and golang.org/x/crypto

Signed-off-by: Akihiro Suda <[email protected]>
cmoulliard added a commit to halkyonio/operator that referenced this issue Dec 12, 2019
… checked and report an error as discovered. See ticket golang/go#33546 for more info
metacosm added a commit to halkyonio/kubedb-capability that referenced this issue Jan 8, 2020
@funnyzpc
Copy link

funnyzpc commented Aug 1, 2020

just remove dependency module from go.mod ,and next update dependency it's ok 😄

@golang golang locked and limited conversation to collaborators Aug 1, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

8 participants