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.

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

Merged

Conversation

tigrannajaryan
Copy link
Member

@tigrannajaryan tigrannajaryan commented Jun 21, 2022

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.

Copy link
Member

@bogdandrutu bogdandrutu left a 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.

README.md Outdated Show resolved Hide resolved
@tigrannajaryan tigrannajaryan force-pushed the feature/tigran/stability branch 2 times, most recently from c571264 to c31c4ae Compare June 21, 2022 14:08
README.md Outdated Show resolved Hide resolved
@tigrannajaryan tigrannajaryan force-pushed the feature/tigran/stability branch from c31c4ae to dd74cc5 Compare June 21, 2022 14:21
@tigrannajaryan
Copy link
Member Author

Be clear that by "now" it means the time when "JSON" is alpha.

@bogdandrutu I have this in the text:

In the future when OTLP/JSON is declared stable, several of the changes that
are currently allowed will become disallowed since they are visible on the wire
for JSON encoding.

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.
Copy link
Member

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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would say no.

README.md Show resolved Hide resolved
- Message names may change.
- Field names may change.
- Enum names may change.
- Enum choice names may change.
Copy link
Member

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?

Copy link
Member

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good, do we need to call it out in the list of allowed changes? This is also somewhat related to @reyang's comment, as it would be UNDEFINED if we don't add it.

- Service names and service package names will not change.
- Service operation names, parameter and return types will not change.

The following changes are allowed:
Copy link
Member

@reyang reyang Jun 28, 2022

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.

Copy link
Member Author

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.
Copy link
Member

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?

Copy link
Member Author

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;

@tigrannajaryan tigrannajaryan force-pushed the feature/tigran/stability branch from dd74cc5 to 2bf5ddc Compare July 5, 2022 19:40
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.
@tigrannajaryan tigrannajaryan force-pushed the feature/tigran/stability branch from 2bf5ddc to d84f877 Compare July 5, 2022 19:40
@tigrannajaryan
Copy link
Member Author

I am merging this since I believe it is an improvement over the current state. If further improvements are desirable please submit new PRs.

@tigrannajaryan tigrannajaryan merged commit e757e74 into open-telemetry:main Jul 5, 2022
@tigrannajaryan tigrannajaryan deleted the feature/tigran/stability branch July 5, 2022 19:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants