-
Notifications
You must be signed in to change notification settings - Fork 265
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 current stability guarantees #406
Clarify current stability guarantees #406
Conversation
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.
Be clear that by "now" it means the time when "JSON" is alpha.
c571264
to
c31c4ae
Compare
c31c4ae
to
dd74cc5
Compare
@bogdandrutu I have this in the text:
Are you looking for more? |
the maturity guarantees, since field names are visible on the wire for JSON encoding. | ||
Components marked `Stable` provide the following guarantees: | ||
|
||
- Field types will not change. |
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.
Is the "optional" attribute considered part of the type?
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 would say no.
- Message names may change. | ||
- Field names may change. | ||
- Enum names may change. | ||
- Enum choice names may change. |
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.
Is it possible to add more Enum values? Above it just says - Numbers assigned to enum choices will not change.
, which would still be fulfilled if adding more choices, right?
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.
It is possible, numbers already assigned cannot be reassigned or changed
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.
- Service names and service package names will not change. | ||
- Service operation names, parameter and return types will not change. | ||
|
||
The following changes are allowed: |
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.
This change covers a list of things that are disallowed and a list of things that are allowed.
What about things that are not included in these lists? - are they allowed or disallowed?
E.g. it'll be great to have one of the following statements:
- Anything that is not in the allowed list, are not allowed.
- Anything that is not in the disallowed list, are allowed.
- Anything that is not in the allowed list AND not in the disallowed list, is currently UNDEFINED and might be allowed/disallowed in the future.
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 we should go with UNDEFINED. That's by default how I think about our specs. If it is not specified then it is undefined and can become defined later.
- Field types will not change. | ||
- Field numbers will not change. | ||
- Numbers assigned to enum choices will not change. | ||
- Service names and service package names will not change. |
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.
What does "service package name" mean?
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.
The package
name where the service
is declared, e.g.:
package opentelemetry.proto.collector.trace.v1; |
dd74cc5
to
2bf5ddc
Compare
This PR captures the current understanding of stability guarnatees. I want to make sure it is explicitly visible until we make a decision on open-telemetry#400 The most likely outcome of open-telemetry#400 is going to be stronger than current definition of "Stable.
2bf5ddc
to
d84f877
Compare
I am merging this since I believe it is an improvement over the current state. If further improvements are desirable please submit new PRs. |
This PR captures the current understanding of stability guarnatees.
I want to make sure it is explicitly visible until we make a decision
on #400
The most likely outcome of #400
is going to be stronger than current definition of "Stable.