how to solve the go.mod conflict when 2 sub-modules point to break version of a common module

[Ian Zhang]

Hi team,

I'm working on a new package, demo, which has a dependency on a and b.

Both a and b are pointing to `go.opentelemetry.io/otel`

a points to go.opentelemetry.io/otel v0.20.0

b points to go.opentelemetry.io/otel v0.25.0

However, the go.opentelemetry.io/otel introduced break changes between these 2 versions.

At v0.25.0, it dropped some functions that exist in v0.20.0 and v0.25.0 has some new functions.

In my demo, the go mod tidy would point to v0.20.0, in this way, it breaks the dependency of b.

I tried to modify the go.mod of demo in order to find a common version between a and b, but I can't

find such.

I wonder if there's a way to let go mod to allow specific module versions for a and b. If not, what's other

possible ways to solve this issue?

Looking forward to your reply.

Ian

[Tamás Gulácsi]

Sorry to say, but go.opentelemetry.io/otel is a dumpster fire of API breakage and flux.

I don't know other solution than modify a or b to use the same version of otel.

[Sean Liao]

As a v0.x.y module, it's explicitly signaling that it may introduce incompatible changes between minor versions, as has happened here. unfortunately for you, a module can only exist at a single version within a build, so you'll have to modify your dependencies.

Some time ago, OpenTelemetry graduated their tracing APIs to stable (v1), committing to maintaining backwards compatibility, so you may want to look at upgrading both your dependencies to target the new, stable version of OpenTelemetry

[Ian Zhang]

Thanks for your reply.

It's sad that a and b are imported but not developed by my team.... I guess I will have to split my demo to smaller modules to make sure a and b are in a different module.

I tried to have something like this,

demo/

    pkg/

        onlya/

            a.go

            go.mod

            go.sum

        onlyb/

            b.go

            go.mod

            go.sum

main.go

go.mod

go.sum

however, in this way the top-level go.mod would still resolve and contain a and b... I guess I will have to put a or b to its own repo.

[Sean Liao]

Splitting the uses of a/b into their own modules/repo won't work if you ultimately import them into a single module.

It would be the same problem, just further down the dependency tree.

[Ian Zhang]

yup, I'm thinking split module, then one of them will leverage the other one's binary..

You are 100% right, when group them together... the top-level dependency tree will break again..

I just hope go.opentelemetry.io/otel will mature soon, then I can drop this workaround.