Add frozen stability level and change default stability level to experimental #170
Conversation
| @@ -200,6 +201,12 @@ def add_md_parser(subparsers): | |||
| required=False, | |||
| action="store_true", | |||
| ) | |||
| parser.add_argument( | |||
There was a problem hiding this comment.
Do you need this? I think the default would be to extend the "brief", and this would be just some extra-prominent formatting.
There was a problem hiding this comment.
Do you mean that when an attribute becomes frozen, we change it's brief to mention it there? It's a viable solution, but then it's harder to read and review, harder to follow the same pattern, and easier to overlook.
It's also not possible to add any checks (if we want to).
I also think it could be useful to add a stability column and represent stability information separately from brief.
semantic-conventions/src/opentelemetry/semconv/model/semantic_attribute.py
Show resolved
Hide resolved
| @@ -314,6 +315,7 @@ def check_stability(stability_value, position): | |||
| "deprecated": StabilityLevel.DEPRECATED, | |||
| "experimental": StabilityLevel.EXPERIMENTAL, | |||
| "stable": StabilityLevel.STABLE, | |||
| "frozen": StabilityLevel.FROZEN, | |||
There was a problem hiding this comment.
"Frozen" is not a stability level but orthogonal to it. https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/document-status.md#feature-freeze
There was a problem hiding this comment.
trying to understand the concern: is it a different term or you'd rather see it as a separate flag?
- If it's a term, we chatted with @reyang and @trask about
frozenvsfeature-freezeand considered (in the long term) changing thefeature-freezetofrozento apply better to things like attributes and be an adjective followingstableordeprecatedpattern. Go usesFrozenconvention for packages to describe that no new features are accepted. - If you'd rather see it as a separate flag:
feature-freezeis still a valid document status used interchangeably withStableorExperimental. Having two attribute parameters would be confusing, as I can write something meaningless as
stability: stable | deprecated
feature-freeze: falseThere was a problem hiding this comment.
2 is what I mean. As you can see in the linked document, a spec document has a lifecylce status and it can be feature-frozen or not. So indeed:
stability: stable | deprecated | experimental(default)
feature-freeze: true | false(default)At least I would suggest adopting the same system for whole spec documents and semantic convention elements, otherwise it could get confusing.
I have no strong opinion on whether that is ideal or if "frozen" should actually be a lifecylce status (optional step between experimental and stable?), but then I think it should be changed in the specs document-status spec first (which itself doesn't state a document status which would make it experimental, whether intentional or not)
There was a problem hiding this comment.
lmolkova
changed the title
|
I was updating the JS semconv package and was very surprised to see the default stability level is stable. We're trying to publish stable separately from experimental in preparation for semconv like HTTP becoming stable soon. Is there any way we can move this forward or at least change the default to experimental? |
|
@dyladan I carved the default part out into #189 since the discussions on open-telemetry/opentelemetry-specification#3456 might still take some time to resolve. |
|
Closing this until we have conclusion on open-telemetry/opentelemetry-specification#3459 and open-telemetry/oteps#232 |
In preparation for open-telemetry/opentelemetry-specification#3279, it'd be great to have a formal way to declare attributes as frozen.