-
Notifications
You must be signed in to change notification settings - Fork 893
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
Make SDK Tracer/Meter/Logger Creation more normative #3529
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.
For small changes, I think the high order bit is to keep consistency across signals https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/sdk.md#tracer-creation.
Done |
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.
These are changes to Stable part of the spec. For every change I believe we need to see an explanation about how this is allowed and is not breaking out stability guarantees.
I updated the description. |
@tigrannajaryan @jack-berg Have I addressed/answered your comments? |
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.
Can you add a changelog entry?
Co-authored-by: Tigran Najaryan <[email protected]>
Done 56b2bef |
How come? Examples where it's not possible? |
Changed to
Which is more clear and explicit |
Changes
Tracer
/Meter
/Logger
instances are always created through aTracerProvicer
/MeterProvider
/LoggerProvider
" is not normative. It is not desired in all languages (see Remove No-Op instrument and Meter creation restrictions #3322). I decided to change the wording to make it is aSHOULD
. Additionally, "SHOULD" makes it as a recommendation to make sure we do not break any existing implementation.(optional)
and parameter names and simply say that the SDK MUST implement the API. This is done in order to minimize the confusion on what is "optional". It also makes the specification more normative. This is not breaking the stability requirements - this is just "fixing the spec".