Semantic Conventions are several years out of date?

[Qard]

From what I can tell the semantic conventions module is auto-generated but hasn't been regenerated in over two years now. It looks like it's using 1.7.0 at the moment while the website currently documents version 1.22.0 which looks quite different. Is there some compatibility reason this hasn't been updated or was it just an oversight?

I'm happy to update it myself, I need to start contributing a bit, just wanted to make sure there wasn't some reason it's that far outdated first. I don't want to go and break everything by updating it. 😅

[Flarna]

Ther are removed and renamed constants. Regeneration likely brakes a lot instrumentations because of this.
As far as I know there are discussion in spec repo to keep the old constants to avoid this but not sure if there is consensus already.

[dyladan]

Is there some compatibility reason this hasn't been updated or was it just an oversight?

Little of both. It started as oversight and it hasn't been completed now for compatibility reasons. We're currently in the process of completely rethinking some of the decisions that caused it to be difficult to update.

[legendecas]

For reference, the tool we are using to generate the sources and its documentation are hosted at: https://github.com/open-telemetry/build-tools/tree/main/semantic-conventions (It's really hard to trace the source of a docker image :( ).

[mx-psi]

Go and the Collector have one sub-package per semantic convention release. That could be a valid approach here.

[david-luna]

@dyladan

We're currently in the process of completely rethinking some of the decisions that caused it to be difficult to update.

Does that mean the way semantic conventions package is generated is going to change?

I think in this case a gradual migration (per package) would be a good approach instead of having a big PR with all the changes. This kind of migration would be possible if

• we keep a copy of the legacy semantic conventions package
• we make all packages to depend on this legacy package
• we generate the latest semantic conventions and check them into the repo

Points 1 & 2 could be done in a single PR (big but not hard to review). Then we can check-in the generated ones and one by one we could migrate from legacy to current SemCon.

We can also think on an update process in the CI to see if a new version of semantic conventions breaks any package.

PS: if approach seems okay we can apply this also to the contrib packages. 1st we need a new release here though

[JamieDanielson]

Chiming in to note that there are likely a few steps to take here, I outlined a bit over on this other issue open-telemetry/opentelemetry-js-contrib#1778 (comment).

For an important tidbit, there are breaking changes with HTTP attributes after v1.20 so we need to be very deliberate about how we update - first to 1.20, then updating further with the OTEL_SEMCONV_STABILITY_OPT_IN environment variable to avoid breaking end users. See this blog post for more detail, and this issue open-telemetry/semantic-conventions#534

[pragmaticivan]

Any chance this will get priority this quarter?

[GimpArm]

I just want to point out that having a single JS library that uses old conventions while every other library in other languages use the new conventions is breaking new software. So being afraid to break old software when the official documentation states that the current values are stable is nonsensical to me.

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[github-actions]

This issue was closed because it has been stale for 14 days with no activity.