This PR lgtm - I had Claude dig into your 1.41 problem and came up with this proposal, wdyt?

The problem, as you pointed out, is breaking name changes. Otel apparently has an answer for this in the spec (messaging semconv):

• messaging - emit the new, stable messaging conventions, and stop emitting the old experimental messaging conventions
• messaging/dup - emit both the old and the stable messaging conventions, allowing for a seamless transition

The default behavior (in the absence of one of these values) is to continue emitting whatever version of the old experimental messaging conventions the instrumentation was emitting previously.

We can implement OTEL_SEMCONV_STABILITY_OPT_IN - otelhttp did it.

Semantics:

• comma-separated list of category tokens; ours is messaging
• messaging: emit stable (new) only
• messaging/dup: emit both old + new (note: span name is single-valued, so dup keeps the old name; only stable flips it)
• unset: keep old (the safe default)
• /dup wins if both appear

Proposal (let me know if you'd want to handle this in this PR or in a new PR): read OTEL_SEMCONV_STABILITY_OPT_IN once in NewTracer, resolve to a mode, and branch on it in the hooks.

This PR lgtm - I had Claude dig into your 1.41 problem and came up with this proposal, wdyt?

The problem, as you pointed out, is breaking name changes. Otel apparently has an answer for this in the spec (messaging semconv):

• messaging - emit the new, stable messaging conventions, and stop emitting the old experimental messaging conventions
• messaging/dup - emit both the old and the stable messaging conventions, allowing for a seamless transition

The default behavior (in the absence of one of these values) is to continue emitting whatever version of the old experimental messaging conventions the instrumentation was emitting previously.

We can implement OTEL_SEMCONV_STABILITY_OPT_IN - otelhttp did it.

Semantics:

• comma-separated list of category tokens; ours is messaging
• messaging: emit stable (new) only
• messaging/dup: emit both old + new (note: span name is single-valued, so dup keeps the old name; only stable flips it)
• unset: keep old (the safe default)
• /dup wins if both appear

Proposal (let me know if you'd want to handle this in this PR or in a new PR): read OTEL_SEMCONV_STABILITY_OPT_IN once in NewTracer, resolve to a mode, and branch on it in the hooks.

Sounds pretty good. I suggest merging this MR so as not to hold adding context to the spans. And I'll bring a new MR this week that will implement the migration to the current version of otel semconv with OTEL_SEMCONV_STABILITY_OPT_IN support in it

Do you think TODO comments should be left on the use of OTEL_SEMCONV_STABILITY_OPT_IN envs? I understand that they are supposed to be removed in the future along with the transition to the new major version.

I investigated what a migration to a more recent version might look like, and it does not appear to be worthwhile at this stage. The main issue is that most of the attributes introduced after 1.18.0 are not yet stable and are still marked as Development. As a result, it is difficult to justify referring to one version as “old” and the other as “stable.” At the same time, such a migration would introduce a considerable amount of additional code without delivering meaningful benefits.

At this point, the most reasonable approach seems to be to add the helpful attributes that already included in this MR, update the dependencies (optional), and remain on version 1.18.0 until the messaging convention reaches stable status. Once that happens, we can introduce the necessary opt-in mechanisms and proceed with the migration

I have an example MR where I implemented the solution described above. Take a look please. You may have some additional thoughts or suggestions on this approach.
Otherwise, I suggest we simply merge the current changes and postpone the migration idea until it becomes worthwhile

@twmb hi, what do you think?

Was delayed by a massive review of #1348... I'm happy with what you're suggesting and waiting for the attributes to be stable.

Test failure is a bug in share fetch sessions (yayyyyy the #1348 audit missed things), I can merge this now.

Was delayed by a massive review of #1348... I'm happy with what you're suggesting and waiting for the attributes to be stable.

Yes, I saw that "monster". It is surprising that such a significant amount of changes only resulted in a patch version bump by 1 😅

Test failure is a bug in share fetch sessions (yayyyyy the #1348 audit missed things), I can merge this now.

Thank you

Released as plugin/kotel/v1.7.0, thanks!