Fixed Schema Telemetry Producers can't be declared stable

[lmolkova]

Let's assume we have two stable instrumentations which don't populate schema URL. One of them implements version X, and another implements version Y (probable case for different languages or different product instrumentations).
Y is backward compatible with X.

If the difference between versions is significant (but Y is backward compatible with X), consumers would likely process and visualize such versions differently.

If version information is missing, consumers might still attempt to detect it, but it would require all consumers to be aware of all past versions of conventions. Also, this is an error-prone, inefficient, and tedious process that we should not expect backends to do.

So if we allow instrumentation to leave schema URL blank, we have to explicitly specify what it means for producers and consumers, how stability is guaranteed: e.g. it's assumed to be the first stable version of this semantic convention. Then all consumers can process such telemetry according to that version and all producers must only implement this version.

Another approach would be to declare all versionless producers to be unstable - any consumer update can break them since consumers can't deduce the version from telemetry and treat it properly

[tigrannajaryan]

Let's assume we have two stable instrumentations which don't populate schema URL. One of them implements version X, and another implements version Y (probable case for different languages or different product instrumentations).
Y is backward compatible with X.

In this hypothetical scenario are two instrumentations different libraries or different versions of the same library? I will assume the question is about different libraries. In that case the consumers can look at the scope name (which contains the library name) and deduce the used schema.

If version information is missing, consumers might still attempt to detect it, but it would require all consumers to be aware of all past versions of conventions. Also, this is an error-prone, inefficient, and tedious process that we should not expect backends to do.

Yes, I agree it is a bad process and places too much burden on the backends. A better process is based on Schema URLs and Schema transforms. The reason for existence of Fixed Schema producers was to serve as a temporary solution until the instrumentation adopts the usage of Schema URLs.

So if we allow instrumentation to leave schema URL blank, we have to explicitly specify what it means for producers and consumers, how stability is guaranteed: e.g. it's assumed to be the first stable version of this semantic convention. Then all consumers can process such telemetry according to that version and all producers must only implement this version.

The stability guaranteed is the following:

• If you find a particular instrumentation library that officially declares itself "Fixed Schema Producer" than you (as a consumer) should expect that that library will use the same version of conventions even when new versions of the library are released. The exact version number of the conventions used may be published by the library author for reference.
• The Fixed Schema Producers may in the future change to become Schema-Driven Producers.

If this is not clear from the spec we can add clarifications.

Another approach would be to declare all versionless producers to be unstable - any consumer update can break them since consumers can't deduce the version from telemetry and treat it properly

It is a possibility. It removes the intermediary "not completely unstable, but also not yet sophisticated enough to use schema urls" state. I don't mind doing it if we think this intermediary state is unnecessary and we think we can increase adoption of schema-driven instrumentations quickly.