Add Requirement Level backward compatibility clarifications #2601
Conversation
|
|
||
| ## Changing requirement level | ||
|
|
||
| Requirement level change is backward compatible if and only if the set of cases when previous version populates it, is a subset of cases when new version would populate it. |
There was a problem hiding this comment.
This definitions is somewhat difficult to unpack. Traditional backwards compatibility is: if my old code is valid in old requirements and still valid in new requirements, then the requirements are backwards compatible (nothing about whether the code populates X or Y). By this traditional definition some changes proposed below are not backwards compatible. For example: Recommended to Required - if my old code did not populate X when X was recommended, the code was still valid since X was still allowed to be skipped, but once X becomes required the code becomes invalid.
There was a problem hiding this comment.
I think it needs to be made clear whether backwards compatibility refers to the telemetry producer (instrumentation) or to the telemetry consumer (backend). It seems to me the changes in this PR refer to consumers.
Changing from Recommended to Required is a breaking change for producers, but not for consumers. Changing from Required to Recommended is a breaking change for consumers, but not for producers.
There was a problem hiding this comment.
I don't think telemetry stability applies to telemetry producers at all. When a new version of semantic conventions is released, producers don't have to update, at least for a long time. They don't need to support the previous version, they don't depend on the telemetry they produce.
If they decide to update, they do it along with the schema version update. If they don't support the schema version, they can't update at all
Almost any semantic convention change would require some action from instrumentations, but none of it seems breaking as long as it's versioned.
There was a problem hiding this comment.
When producer don't populate schema version, almost any change would break it:
- adding new required attribute (which is considered non-breaking, maybe accidentally)
- attribute rename, which is not really classified, but allowed
I understand the concern though, but there is nothing we can do for producers that don't version telemetry if we want to evolve conventions
There was a problem hiding this comment.
Created #2606 to discuss further.
There was a problem hiding this comment.
I'd consider removing this sentence. It seems to restate the sentence on line 76 with less clarity.
|
|
||
| ## Changing requirement level | ||
|
|
||
| _Note: Requirement level compatibility applies to telemetry consumers only. When semantic convention is updated from version `X` to version `Y` in a backward-compatible manner, consumers that only support version `X` would be fully compatible with telemetry version `Y`._ |
There was a problem hiding this comment.
These rules only apply to stable semantic conventions, correct? Might be worth noting that.
Co-authored-by: jack-berg <[email protected]>
|
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
|
Closed as inactive. Feel free to reopen if this PR is still being worked on. |
Added backward-compatibility section to requirement levels to address #2594 (review)
/cc @bogdandrutu