Propose ideas for sending otlp_version in OTLP payloads

[felixge]

The goal would be to allow the profiling signal to make breaking changes after alpha without breaking downstream consumers. I.e. encouraging more usage of the alpha. This was discussed in the 2026-03-05 meeting.

[florianl]

As mentioned in the meeting, something like an telemetry.otlp.version attribute (maybe attached to the Scope... messages) in OTel SemConv could be used to identify the OTLP version to components.

[felixge]

I can see how an attribute on Scope... messages would make sense. OTOH it's gonna be the same key/val pair for every scope, which is a bit awkward. For non-profiling signals it may also be a bit of overhead, but I guess that wouldn't be the main use case.

So far I was thinking about a dedicated otlp_version field in the proto(s) or a HTTP header (gRPC metadata).

But what you're proposing might be the easiest thing to align on ... so it's worth exploring!

[Gandem]

If we plan to introduce breaking changes at the protobuf level when moving from alpha to beta/stable, putting the version in the payload won’t work.

If the field layout changes (field numbers, types, etc.), the decoder needs to know which schema to use upfront. Otherwise it might misinterpret the bytes, drop fields, or just fail to decode. And since the version would only be available after parsing, it could be too late to help with that.

So the version probably needs to live outside the payload, e.g. in an HTTP header or gRPC metadata.

[dmathieu]

I think we also need to keep in mind that the version shouldn't be needed anymore once we reach stability. Nor will we need it for any other signal.
If we work on a v2 someday, it will be an entirely different grpc path.

So going for headers/metadata seems to be the best approach.
I also think handling transformation of the data between versions is a bit of an overengineering.
Rejecting pushes if the versions don't match should be enough.