Updating @opentelemetry dependencies

[seanparmelee]

Hello 👋

I was looking over both the compatibility matrix and the versioning and stability documents and was looking to get clarification/guidance around updating open telemetry dependencies.

We have an internal tracing package that has a number of open telemetry packages listed as peerDependencies that align with

API Version	Core version	Experimental Packages
1.1.x	1.5.x	0.31.x

But the version ranges we set for these peers are pretty loose, allowing for some consuming apps to end up having

API Version	Core version	Experimental Packages
1.2.x	1.6.x	0.31.x

The versioning and stability document had me thinking this should be fine, but the compatibility matrix and the mess of transitive dependencies in such an app has me thinking otherwise.

Should I be interpreting the compatibility matrix to mean that we should not be mixing version ranges of the package types (such as using 0.31.x experimental packages with 1.6.x core packages)?

I guess I'm ultimately wondering if we should tighten down our peers to only allow for patches and make sure apps are following the compatibility matrix such that any updates to the open telemetry dependencies are 1) done in lock step and 2) align with a row in the matrix.

[Flarna]

It depends a bit on which packages you use. In some cases it's don't care in others its problematic.
Two examples:

1. you use @opentelemetry/instrumentation@0.31.0
   This depends on "@opentelemetry/api-metrics": "0.31.0" and peer depends on "@opentelemetry/api": "^1.0.0" and transitive to "@opentelemetry/api": "^1.0.0"
   Therefore this fits fine with 1.6.0 Core and 1.2.0 API and should work
2. you use @opentelemetry/sdk-node@0.31.0
   This depends on e.g. "@opentelemetry/sdk-trace-base": "1.5.0" (and more pinned 1.5.0 versions)
   Clearly this is problematic and likely wont work well

One more issue regarding use of ranges is that some packages are GA and others are experimental. NPM acts different for 0.x range:

• "^1.5.0" allows 1.5.1 and 1.6.0,...
• "^0.31.0" allows 0.31.1 but not 0.32.0

Therefore pinning experimental and using ~ for Core is likely a good choice for stability.

The really hard task is once packages from other repos are used (incl. opentelemetry-js-contrib) as they have their own release cycle and dependency management and I'm not aware of any table to help.

[seanparmelee]

Thanks for confirming @Flarna!

The really hard task is once packages from other repos are used (incl. opentelemetry-js-contrib) as they have their own release cycle and dependency management and I'm not aware of any table to help.

Agreed! I didn't mention this earlier, but some of the packages we are using are from opentelemetry-js-contrib and we certainly noticed the differences in dependency management.