OpenTelemetry has a stable instrumentation BOM: https://mvnrepository.com/artifact/io.opentelemetry.instrumentation/opentelemetry-instrumentation-bom/2.15.0

We depend on spring boot to manage OpenTelemetry version for us, through the BOM. However, it does not include the opentelemetry instrumentation BOM, so when we want to use functionality from OpenTelemetry instrumentation, we have to manually keep that version aligned with the SDK version that spring boot applies.

This is a pain, because now I have to: 1. Look up spring-boot-dependencies/build.gradle to check which OpenTelemetry BOM is applied. 2. Go to opentelemetry-java-instrumentation releases and check the release notes, to see which instrumentation version targets the SDK version that spring boot is applying. 3. Apply that instrumentation version to my own project(s). 4. Repeat this manually, every time I update spring boot version.

This should be a simple change to add, and I'm happy to raise a PR. Just depend on the instrumentation BOM instead of the plain opentelemetry BOM. Since, the instrumentation BOM includes the OpenTelemetry BOM. These are all stable (there are different BOMs for alpha versions).

Comment From: bclozel

I'm not sure we can as this BOM depends on Spring Boot itself so this would create a dependency cycle. Even if we could partially import it, the release cadence seems to be out of cycle with Spring Boot itself. There are minor releases fairly often and Spring Boot would not be able to upgrade so often. I guess maintaining an up-to-date instrumentation is important.

Comment From: wilkinsona

For the reasons described by @bclozel, this isn't something that we can do. Furthermore, to keep its scope manageable, we also try to only manage that versions of dependencies with which Spring Boot itself interacts. We don't publish any artifacts that depend upon anything managed by the instrumentation bom so it isn't something that we'd really want to manage even without the release cadence and circular dependency problems. Thanks anyway for the suggestion.

Comment From: jonatan-ivanov

It does not matter from the perspective of the outcome (see the comments above) but: - opentelemetry-instrumentation-bom has a history of increasing minor versions of opentelemetry-bom in patch releases - "stable" artifacts in OpenTelemetry has a history of having "unstable" (-alpha) dependencies (which means "unstable" for many Boot users) - If my understanding is correct, since Spring Boot does not instrument nor tests itself using OTel Instrumentation, managing the OTel Instrumentation version could falsely suggest the users that a given version of OTel Instrumentation works with the current version of Spring Boot. You would still need to check the OTel release notes to see which instrumentation version works with the given version of Spring Boot since nothing guarantees that the OTel Instrumentation version that Boot provides works with that version of Boot.

Comment From: jamesmoessis

Thanks folks - the circular dependency thing is something I didn't think of. Makes sense for that to be a blocker. I will have to figure something out on my end to keep the versions aligned.

I think this is something you will eventually need to figure out if you want to use OpenTelemetry semantic conventions.

Comment From: jonatan-ivanov

Semconv should not have the circular dependency issue since it should have no dependencies. As for managing the semconv version, I think OTel should fix this: https://github.com/open-telemetry/opentelemetry-java/issues/7279

Comment From: jamesmoessis

Thanks @jonatan-ivanov, I've commented on that issue. I agree they should move semconv into the main BOM.