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

$ go version go1.14.1 linux/amd64

Does this issue reproduce with the latest release?

yes

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

$ go env
GO111MODULE="on"
GOARCH="amd64"
GOBIN="/home/ing/go/bin"
GOCACHE="/home/ing/.cache/go-build"
GOENV="/home/ing/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GONOPROXY="bitbucket.org/redeam"
GONOSUMDB="bitbucket.org/redeam"
GOOS="linux"
GOPATH="/home/ing/go"
GOPRIVATE="bitbucket.org/redeam"
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/ing/go/src/bitbucket.org/redeam/reseller-notifications/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-build515087672=/tmp/go-build -gno-record-gcc-switches"

What did you do?

We're using modules in a project that already broke the v2+ rules regarding package structure before modules were a thing, we would still like to be able to use modules and so far have been able to by adding +incompatible to the module require statement when importing the project in question.

While this allows go test and go build to work is causes go mod download to fail.

I understand the point of having best practices and forcing +incompatible on packages that break these practices but there should not be anything that stops us from doing this if we explicitly set it as such.

My concern is if download is broken today and not test and build, is it likely that test and build will eventually follow this behavior? If that's the case it will break a number of things in our stack; I don't think it makes sense to break users, whether for the "greater good" or not.

It's worth noting that go mod vendor also works currently, if there are no plans to change this behavior with relation to test, build and vendor then this is not an issue but I would rather find out ahead of time if this behavior is likely to change for the reason listed above.

What did you expect to see?

all packages downloaded successfully

What did you see instead?

bitbucket.org/redeam/core@v3.5.7+incompatible: invalid version: +incompatible suffix not allowed: module contains a go.mod file, so semantic import versioning is required