-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
semconv: Backwards compatibility with v0 with v1? #2577
Comments
cc @dashpole |
This is the same situation we have in the kubernetes/kubernetes codebase as well. We have a dependency on Etcd, which hasn't released a new minor release in a while, and are stuck on a v0 release of otel-go. Etcd's v3.6.0 release should be happening quite soon according to etcd-io/etcd#13538, after which we will both be unblocked. |
I think the right answer here is probably to sit tight for a few weeks while we wait for them to release. If we did want to make v1 backwards-compatible with v0, it would take a lot more than |
IIUC the compatibility seems permanently broken for the package
UPDATE: i failed unwind by upgrade either, b/c k8s apiserver library relies on |
So that things are cross-linked, here is the related Kubernetes issue: kubernetes/kubernetes#106536 |
for those with issues here - the 3.6.0-alpha.0 of etcd is out. solved my dependencies issues. |
Closing as the underlying issue looks resolved. Please reopen if this is in error. |
For anyone hitting this on etcd v3.5.x - Upgrade to at least v3.5.5 and the otel deps have been bumped upstream. No need to run the 3.6.0 alpha. |
Problem Statement
The refactoring of
semconv
has lead to some interesting problems when attempting to vendor multiple dependencies for our codebase.While
v0
versions per Semantic Versioning are inherently unstable, having backwards compatibility withv0
while onv1
would be extremely helpful, as Go Modules do not currently keep two separate versions when it'sv0/v1
, and only do that for later versions.Proposed Solution
Including the previously deleted code for
semconv
in the directory in which it used to live, would allow folks who still have packages which depend onv0
versions ofotel
live simultaneously with code that depends on newer versions.Alternatives
I have also filed an issue for
etcd
for the particular issue I'm encountering, but also asking here as a more general solution: etcd-io/etcd#13664The text was updated successfully, but these errors were encountered: