opentelemetry-js-api
opentelemetry-js-api copied to clipboard
Consider renaming Link#context -> Link#spanContext
Span#context
was renamed in https://github.com/open-telemetry/opentelemetry-js-api/pull/45. For consistency, it would be nice if link did the same. https://github.com/open-telemetry/opentelemetry-js-api/blob/9b3f9c75a57190841b5f091933932386f63a62ac/src/trace/link.ts#L37
This is a minor ask – if we don't want to create more API churn this can be closed 🙂
This will not make it into the 1.0 release. We can add it after 1.0 as a minor addition and mark the previous property as deprecated.
Is there already a deprecation workflow defined? For example node.js has 3 types of deprecations where doc deprecated is the only one which is not semver major.
The spec versioning doc has only made affordances for deprecating whole signals, not individual API methods and properties.
I will open a PR with an official deprecation strategy along these lines:
- Add
@deprecated
tsdoc flag with a note pointing to the new function or some upgrade strategy if applicable. - In the next major release, all previously
@deprecated
functions are removed. This will likely be much later.
2\. In the next major release, all previously `@deprecated` functions are removed. This will likely be much later.
Maybe we should add also a minimum timeframe for removing, or use a whole major cycle. This may be terrible long as there is no release plan for next majors as far as I know.
Currently a new major seems to be in the far future. But with this proposal it would be allowed to add an @deprecated
label a few days before a new major is created where the API is then gone.
Good suggestion. I think at least a whole major cycle is likely to be extremely long. How about next major release unless the release happens within 6 months of deprecation, else the removal must wait for the next major release after that.
I would also say introducing a @deprecated
flag is a semver-minor change, not patch, and it must come along with a documented alternative solution.
This rename is a breaking change and I don't see a strong benefit to deprecate the old name. If someone thinks this is causing unnecessary confusion they can open an issue in https://github.com/open-telemetry/opentelemetry-js as this package is moving there.