cmd/go: accept tags of the form X.Y.Z (without leading 'v') as semantic versions

[tamalsaha]

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

$ go1.13beta1 version
go version go1.13beta1 linux/amd64
$ go version
go version go1.12.6 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

GOARCH="amd64"
GOBIN=""
GOCACHE="/home/tamal/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/tamal/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
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-build803673677=/tmp/go-build -gno-record-gcc-switches"

What did you do?

$ go1.13beta1 get github.com/kubedb/apimachinery@v0.11.0
go: finding github.com/kubedb/apimachinery v0.11.0
go: finding github.com/kubedb/apimachinery v0.11.0
go: finding github.com v0.11.0
go: finding github.com/kubedb v0.11.0
go get github.com/kubedb/apimachinery@v0.11.0: unknown revision v0.11.0

$ go1.13beta1 get github.com/kubedb/apimachinery@0.11.0
go: finding github.com/kubedb/apimachinery 0.11.0

We use the git tag also as the Docker image tag. I like kubedb/operator:1.0.0 (without v) over kubedb/operator:v1.0.0. So, we went with that. Tools like glide, dep will automatically handle the presence or absence of v. But go mod does not do that.

What did you expect to see?

My question is can go mod automatically search for both of these prefixes?

What did you see instead?

[rsc]

No change in consensus, so declined. — rsc for the proposal review group