Skip to content
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.

Sign up for GitHub

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

Merged
merged 2 commits into from
Oct 20, 2020
Merged

Clarify maturity guarantees #225

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
0c5c9da
Clarify maturity guarantees
Oct 16, 2020
b85e351
Made a few fixes based on PR comments
Oct 19, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 8 additions & 0 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -24,6 +24,14 @@ All messages | Alpha |
(See [maturity-matrix.yaml](https://github.com/open-telemetry/community/blob/47813530864b9fe5a5146f466a58bd2bb94edc72/maturity-matrix.yaml#L57)
for definition of maturity levels).

Note that maturity guarantees apply only to wire-level compatibility for the binary
Protobuf serialization. Neither message, 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
Copy link
Member

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?

Copy link
Member Author

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

Copy link
Member

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.

the maturity guarantees, since field names are visible on the wire for JSON encoding.

## Experiments

In some cases we are trying to experiment with different features. In this case
Expand Down