Go version

go version go1.23.1 linux/amd64

Output of go env in your module/workspace:

GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/home/me/.cache/go-build'
GOENV='/home/me/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/home/me/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/me/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.23.1'
GODEBUG=''
GOTELEMETRY='local'
GOTELEMETRYDIR='/home/me/.config/go/telemetry'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/dev/null'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build140071008=/tmp/go-build -gno-record-gcc-switches'

What did you do?

I've created the following project - Module X uses Module Y at version A - My project use module X and Module Y at version B - Version B is newer than version A - both A and B are not stable versions (my code is not tagged yet as it is in-development yet) - Version B is not backward compatible with version A ofc and vice-versa

Steps to reproduce I'm a bit lazy so I'll not create a gh repo with the demo but I'll provide steps to reproduce my situation 
cd /tmp/
mkdir testrepo
cd testrepo
go mod init example.com
go get github.com/AllenDang/giu@v0.8.1 // my Module X (using Module Y at version A)
go get github.com/AllenDang/cimgui-go@5457515 // my Module Y at version B
then, put this code in `main.go` 
package main

import (
    imgui "github.com/AllenDang/cimgui-go"
    "github.com/AllenDang/giu"
)

func main() {
    giu.NewMasterWindow("window", 800, 600, 0)
    imgui.CurrentIO()
}
and run `go build .` if you do `go get -u github.com/AllenDang/cimgui-go@9ebf619d1d03` it will build correctly

What did you see happen?

It seems that go decided to force Module X use Module Y at version B what resultet in build failure.

What did you expect to see?

if version is v0.* go should handle each commit as another version and respect go.mod require directive correctly.

Comment From: gabyhelp

Related Issues and Documentation

(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)

Comment From: seankhliao

this is working as intended, each unique import path can only exist at a single version, we're not going to allow the confusion of having the same name mean different things

Comment From: gucio321

ok, sounds reasonable.

Comment From: gucio321

@seankhliao I just tought about this issue a little bit more and now it doesn't seem so clear to me.

Lets take a look at the following example: - Module Y added a function called Foo and was tagged as v0.1.0 - then, function Foo was renamed as Bar and this change was tagged v0.2.0 - lets note that according to Semantic Versioning Module Y was allowed to do this as v0.* is dev version and it has no backward compatibility - now Module X uses v0.1.0 and uses Foo() - now Module Z imports Module X and (also) imports Module Y but with version v0.2.0 (sorry, if I'm repeating the OP but I just wanted to add more details to my example).

I think that everyone should agree that this setup should work, because why it shouldn't?

we're not going to allow the confusion of having the same name mean different things

My answer is, that import paths are determined in module's go.mod file, this is what are go.mos for, right? So I see no reason why import paths should not change meaning in the area of certain module.