-
Notifications
You must be signed in to change notification settings - Fork 267
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarify maturity guarantees #225
Clarify maturity guarantees #225
Conversation
This clarifies what is and is not part of the promises.
@open-telemetry/specs-approvers please review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm only a specs-trace-approver, so not sure if my approval formally counts, but LGTM!
field, nor enum names of Protobuf messages are visible on the wire and are not | ||
considered part of the guarantees. We are free to make change to the names. | ||
|
||
In the future when OTLP/JSON is declared stable, field names will also become part of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think OTLP/JSON should just always be left unstable. I think the cost/benefit ratio to declaring this stable is just not right. Are there any strong reasons for supporting JSON at all?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Short answer: yes, we want it, but I am not sure we want to open this discussion here in this PR. OTLP/JSON is already part of the specification: https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/protocol/otlp.md#request
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think @Oberon00 has good arguments (probably more in his mind). Would be good to have this discussion, also may be good to discuss if JSON should be based on these protos or we defined it separately.
8947d65
to
b85e351
Compare
This clarifies what is and is not part of the promises.