You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When reporting schema version instrumentations should be able to differentiate which one they report - the stable or stable with experimental features.
For example, HTTP client span with schema URL pointing to v1.28.0 would have additional attributes if experimental ones are enabled.
To reduce the ambiguity, we can publish two schema urls:
one that represents a stable part of semantic conventions, e.g. https://opentelemetry.io/schemas/1.29.0
another one that contains all conventions, e.g. https://opentelemetry.io/schemas/1.29.0-alpha following semver pre-release version
This also allows to communicate stability guarantees to the consumers of this telemetry.
To support it, we'd need
start publishing two documents on https://opentelemetry.io/schemas/* (existing schema-next files should be used for experimental part, we'll need new ones for stable part - which should be empty).
When reporting schema version instrumentations should be able to differentiate which one they report - the stable or stable with experimental features.
For example, HTTP client span with schema URL pointing to v1.28.0 would have additional attributes if experimental ones are enabled.
To reduce the ambiguity, we can publish two schema urls:
https://opentelemetry.io/schemas/1.29.0
https://opentelemetry.io/schemas/1.29.0-alpha
following semver pre-release versionThis also allows to communicate stability guarantees to the consumers of this telemetry.
To support it, we'd need
schema-next
files should be used for experimental part, we'll need new ones for stable part - which should be empty).The text was updated successfully, but these errors were encountered: