trace moved from otel/api/trace into otel

[yogo1212]

open-telemetry/opentelemetry-go@27c84d6#diff-14c2529eb4498c5d1ffd6915d05bf58a91bdda796af59f41d480d11c099d0479

Not this sure this workflow works at all.

[vmihailenco]

Such update should wait until Otel v0.14 is released.

[yogo1212]

@vmihailenco i read up a bit on how to use the go module system [1] and it appears to me this is a problem concerning redis and opentelemetry.

go sees the tag in go.mod as a 'minimum version'. as a consequence, their recommendation is this:

Packages intended for public use should try to maintain backwards compatibility as they evolve. The Go 1 compatibility guidelines are a good reference here: don’t remove exported names, encourage tagged composite literals, and so on. If different functionality is required, add a new name instead of changing an old one. If a complete break is required, create a new package with a new import path.

API changes like the added context in go-redis and opentelemetry's moved API make updates (go get -u) break existing code.

[1] https://research.swtch.com/vgo-principles

[yogo1212]

EDIT: opentelemetry-go aims to improve their readme to more clearly state that the API is not yet stable.

open-telemetry/opentelemetry-go#1279

[vmihailenco]

There are 2 unrelated problems:

1. you are NOT using Go modules correctly
2. OpenTelemetry API is not stable yet

We can't do anything about the 2), but you definitely can/should use Go modules.

go get -u break existing code

It does not (until there is a new Otel release with breaking changes). I have multiple projects and go get -u does NOT update opentelemetry to an unreleased version and therefore does NOT break the build. If you are using Go modules.

[yogo1212]

@vmihailenco i've come to a different conclusion on what was intended with and what can be expected of go modules than you.
in a typical server deployment or image building process, one checks out the project and runs go get. and that's all fine - regardless of whether or not the project itself uses modules to manage dependencies (i.e. uses code from $GOPATH/src or from $GOPATH/pkg/mod).

my concern is about running go get -u.
this doesn't work - regardless of whether go modules are being used or not.
in its go.mod, go-redis specifies that i can run with any version of otel that's "at least" v0.13.0 and that is simply not true.
the import compatibility rule is critical for this process to succeed. even with manual oversight, the problem can only be tackled using ugly workarounds.

These kinds of changes require effort by downstream users to migrate their code to the new API, so they should not be made without careful consideration that the benefits outweigh the costs

i'm one of those users. i won't tell you that it's your mistake to use opentelemetry - that discussion was taken to their issue tracker.

what i will say is that go-redis added the context parameter and that i'd rather have fixed a few deprecation warnings at a time of my chosing than to squeeze in changes during deployment.
this time around (opentelemetry, indirect dependency), that won't work without diverging from go-redis upstream.

[yogo1212]

to be clear on why this can still break when the project using go-redis uses modules:

Each different major version (v1, v2, and so on) of a Go module uses a different module path: starting at v2, the path must end in the major version. In the example, v3 of rsc.io/quote is no longer rsc.io/quote: instead, it is identified by the module path rsc.io/quote/v3. This convention is called semantic import versioning, and it gives incompatible packages (those with different major versions) different names. In contrast, v1.6.0 of rsc.io/quote should be backwards-compatible with v1.5.2, so it reuses the name rsc.io/quote. (In the previous section, rsc.io/sampler v1.99.99 should have been backwards-compatible with rsc.io/sampler v1.3.0, but bugs or incorrect client assumptions about module behavior can both happen.)

it is impossible for a program to build with both rsc.io/quote v1.5.2 and rsc.io/quote v1.6.0.

When a higher version number for otel is checked out or requested via another dependency or the main project, that higher version will be used and go-redis won't compile.