* Clarify that Trace/Meter are associated with Instrumentation Scope
This is a slightly different take on https://github.com/open-telemetry/opentelemetry-specification/issues/2203
Instead of renaming instrumentation library to instrumentation scope everywhere
this PR suggests targetted editing of wording of the Trace/Meter obtaining API
to allow not just instrumentation library but other instrumentation scopes to be
used as a parameter.
This change does not force renaming of API parameters and is not a breaking change.
We consider it a clarification of usage to match the intent that we had for the "name"
field.
If this PR is accepted there will be a follow up PR that will suggest to rename
InstrumentationLibrary* messages in OTLP proto to InstrumentationScope* message.
Such a change will not be a breaking change for the OTLP wire format and is acceptable.
If this PR is accepted we will also close https://github.com/open-telemetry/opentelemetry-specification/pull/1236
since it will be no longer necessary. The logger name will be recorded as the
instrumentation scope. This clarification will be a follow up PR that clarifies the
behavior in https://github.com/open-telemetry/oteps/blob/main/text/logs/0150-logging-library-sdk.md
* Prohibit usage of retired names in semantic conventions
This change adds a prohibition clause that requires that no old
metric or attribute name is used for a new attribute.
This is important to ensure reversibility of schema transformation
(converting from a new version to an old version of schema).
Without this restriction the following is possible:
Schema version 1. Attribute A exists.
Schema version 2. Attribute A is renamed to B. Appropriate schema file is created.
Schema version 3. Attribute A is introduced (a completely different new attribute).
Now attempting to go from Version 3 to version 1 is impossible since it requires
renaming B to A (for the change in version 2), but a different attribute A already exists.
* Fix based on comments
* Add changelog entry
Co-authored-by: Carlos Alberto Cortez <calberto.cortez@gmail.com>
* Clarify that Trace/Meter are associated with Instrumentation Scope
This is a slightly different take on https://github.com/open-telemetry/opentelemetry-specification/issues/2203
Instead of renaming instrumentation library to instrumentation scope everywhere
this PR suggests targetted editing of wording of the Trace/Meter obtaining API
to allow not just instrumentation library but other instrumentation scopes to be
used as a parameter.
This change does not force renaming of API parameters and is not a breaking change.
We consider it a clarification of usage to match the intent that we had for the "name"
field.
If this PR is accepted there will be a follow up PR that will suggest to rename
InstrumentationLibrary* messages in OTLP proto to InstrumentationScope* message.
Such a change will not be a breaking change for the OTLP wire format and is acceptable.
If this PR is accepted we will also close https://github.com/open-telemetry/opentelemetry-specification/pull/1236
since it will be no longer necessary. The logger name will be recorded as the
instrumentation scope. This clarification will be a follow up PR that clarifies the
behavior in https://github.com/open-telemetry/oteps/blob/main/text/logs/0150-logging-library-sdk.md
* Prohibit usage of retired names in semantic conventions
This change adds a prohibition clause that requires that no old
metric or attribute name is used for a new attribute.
This is important to ensure reversibility of schema transformation
(converting from a new version to an old version of schema).
Without this restriction the following is possible:
Schema version 1. Attribute A exists.
Schema version 2. Attribute A is renamed to B. Appropriate schema file is created.
Schema version 3. Attribute A is introduced (a completely different new attribute).
Now attempting to go from Version 3 to version 1 is impossible since it requires
renaming B to A (for the change in version 2), but a different attribute A already exists.
* Fix based on comments
* Add changelog entry
Co-authored-by: Carlos Alberto Cortez <calberto.cortez@gmail.com>