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

Is it possible to rename "instrumentation library" to "instrumentation scope"? #2431

Closed
tigrannajaryan opened this issue Dec 6, 2021 · 2 comments
Assignees
Labels
enhancement New feature or request
Milestone

Comments

@tigrannajaryan
Copy link
Member

This initially came from a discussion about introducing Logger Name.

While discussing the issue during the spec SIG meeting we came to a conclusion that the intent for "instrumentation library" was actually to have an "instrumentation scope".

The "instrumentation library" is currently used throughout the spec API and SDK. We want to explore if it is possible to rename "instrumentation library" to "instrumentation scope" without breaking existing stability guarantees.

This issue is a questions for the maintainers of this repo: are we able to do this in a non-breaking manner?

Note: this should be only done if it is not a breaking change. We must continue honouring our stability guarantees.

Warning: please don't make the actual change yet. We need to confirm first that it is possible to make this change everywhere before moving forward.

Spec issue recorded here: open-telemetry/opentelemetry-specification#2203

@MrAlias
Copy link
Contributor

MrAlias commented Dec 7, 2021

It is not going to be possible to rename "instrumentation library" to "instrumentation scope" without introducing a breaking change. There is the SDK type itself,

type Library struct {

As well as things like the read-only span interface,

InstrumentationLibrary() instrumentation.Library

Changing these names will be breaking changes that would violate our stability guarantees.

It might be possible to add new types, options, and methods, and deprecate the old ones. I would have to probably go through the changes a bit more carefully if we wanted to go this route, but I'm not sure it would serve us in the long run.

@tigrannajaryan
Copy link
Member Author

It appears the conclusion of many SDKs is that this is not a possible change. Closing. Thanks for checking.

@pellared pellared added this to the untracked milestone Nov 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

5 participants