chore: prepare release API 1.9.0/Core 1.25.0/Experimental 0.52.0

[pichlermarc]

API 1.9.0

🚀 (Enhancement)

• feat(api): allow adding span links after span creation #4536 @seemk
  • This change is non-breaking for end-users, but breaking for Trace SDK implementations in accordance with the specification as new features need to be implemented.
• feat: support node 22 #4666 @dyladan

Core 1.25.0

🚀 (Enhancement)

• feat(instrumentation): generic config type in instrumentation base #4659 @blumamir
• feat: support node 22 #4666 @dyladan
• feat(sdk-trace-node): support xray Propagator via OTEL_PROPAGATORS environment variable #4602 @anuraags

🐛 (Bug Fix)

• fix(core): align inconsistent behavior of getEnv() and getEnvWithoutDefaults() when a process polyfill is used #4648 @pichlermarc
  • getEnvWithoutDefaults() would use process.env if it was defined when running in a browser, while getEnv() would always use _globalThis. Now both use _globalThis when running in a browser.
• fix(resources): prevent circular import (resource -> detector -> resource -> ...) #4653 @pichlermarc
  • fixes a circular import warning which would appear in rollup when bundling @opentelemetry/resources

Experimental 0.52.0

💥 Breaking Change

• feat(exporter--otlp-)!: move serialization for Node.js exporters to @opentelemetry/otlp-transformer #4542 @pichlermarc
  • Breaking changes:
    • (user-facing) convert() now returns an empty object and will be removed in a follow-up
    • (internal) OTLPExporterNodeBase now has additional constructor parameters that are required
    • (internal) OTLPExporterNodeBase now has an additional ResponseType type parameter
• feat(exporter--otlp-)!: move serialization for Node.js exporters to @opentelemetry/otlp-transformer #4581 @pichlermarc
  • Breaking changes:
    • (user-facing) convert() has been removed from all exporters
    • (internal) OTLPExporterBrowserBase: RequestType has been replaced by a ResponseType type-argument
    • (internal) OTLPExporterNodeBase: ServiceRequest has been replaced by a ServiceResponse type-argument
    • (internal) the @opentelemetry/otlp-exporter-proto-base package has been removed, and will from now on be deprecated in npm

🚀 (Enhancement)

• feat(instrumentation): add util to execute span customization hook in base class #4663 @blumamir
• feat(instrumentation): generic config type in instrumentation base #4659 @blumamir
• feat: support node 22 #4666 @dyladan
• feat(propagator-aws-xray-lambda): add AWS Xray Lambda propagator 4554

1.25.0

🚀 (Enhancement)

• feat: support node 22 #4666 @dyladan
• feat(sdk-trace-node): support xray Propagator via OTEL_PROPAGATORS environment variable #4602 @anuraags

🐛 (Bug Fix)

• fix(core): align inconsistent behavior of getEnv() and getEnvWithoutDefaults() when a process polyfill is used #4648 @pichlermarc
  • getEnvWithoutDefaults() would use process.env if it was defined when running in a browser, while getEnv() would always use _globalThis. Now both use _globalThis when running in a browser.
• fix(resources): prevent circular import (resource -> detector -> resource -> ...) #4653 @pichlermarc
  • fixes a circular import warning which would appear in rollup when bundling @opentelemetry/resources
• fix(exporter-metrics-otlp-grpc): add explicit otlp-exporter-base dependency to exporter-metrics-otlp-grpc #4678 @AkselAllas

[dyladan]

I reached out to Datadog about this through @Qard. As the PR currently stands it would break dd-trace which I would like to avoid. I think we should delay this for a short time in order to allow them to respond, but I don't want to delay it forever.

[Qard]

I've forwarded it to the relevant person internally so hopefully we'll come up with some solution soon...

[hamin]

Any chance of #4536 enhancement having a published release soon? I realize there's a breaking change with a dd lib but was hoping to have the enhancement in a release sooner than that's resolved?

Appreciate everyone's efforts here.

[hamin]

Any chance of #4536 enhancement having a published release soon? I realize there's a breaking change with a dd lib but was hoping to have the enhancement in a release sooner than that's resolved?

Appreciate everyone's efforts here.

@Qard @dyladan Any chance the dd-trace blockers don't hold back API 1.9.0 enhancements? Is it possible to have a release for API without waiting on dd-trace resolution? Thank you in advance!

[dyladan]

It's possible but it's not ideal. If we release in the current state we will definitely break dd-trace and it reflects poorly on the project. We're doing our best to work with them. Sorry it's delaying the release but please be patient and we'll have a release soon.

[dyladan]

We're going to move forward with this change next week. It looks to me like dd-trace hasn't done anything yet to address the issue, but we have been very clear for months. @pichlermarc please update this PR and we can get it merged when I get back.