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

[pichlermarc]

1.9.0

🚀 (Enhancement)

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

1.25.0

🚀 (Enhancement)

• feat: support node 22 #4666 @dyladan
• feat(context-zone*): support zone.js 0.12.x #4376 @maldago
• refactor(core): Use tree-shakeable string constants for semconv #4739 @JohannesHuster
• refactor(shim-opentracing): Use tree-shakeable string constants for semconv #4746 @JohannesHuster
• refactor(sdk-trace-web): Use tree-shakeable string constants for semconv #4747 @JohannesHuster
• refactor(sdk-trace-node): Use tree-shakeable string constants for semconv #4748 @JohannesHuster
• refactor(sdk-trace-base): Use tree-shakeable string constants for semconv #4749 @JohannesHuster
• refactor(resources): update deprecated semconv to use exported strings #4755 @JamieDanielson
• refactor(exporters): update deprecated semconv to use exported strings #4756 @JamieDanielson

📚 (Refine Doc)

• refactor(examples): use new exported string constants for semconv in examples/esm-http-ts #4758 @Zen-cronic
• refactor(examples): use new exported string constants for semconv in examples/basic-tracer-node #4759 @Zen-cronic
• refactor(examples): use new exported string constants for semconv in examples/http #4750 @Zen-cronic
• refactor(examples): use new exported string constants for semconv in examples/grpc-js #4760 @Zen-cronic
• refactor(examples): use new exported string constants for semconv in examples/otlp-exporter-node #4762 @Zen-cronic
• refactor(examples): use new exported string constants for semconv in examples/opentracing-shim #4761 @Zen-cronic

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
• feat(instrumentation): remove default value for config in base instrumentation constructor #4695: @blumamir
• fix(instrumentation)!: remove unused supportedVersions from Instrumentation interface #4694 @blumamir
• feat(instrumentation)!: simplify registerInstrumentations() API
  • Breaking changes:
    • removes InstrumentationOptions type
    • occurrences of InstrumentationOptions are now replaced by (Instrumentation | Instrumentation[])[]
      • migrate usages of registerInstrumentations({instrumentations: fooInstrumentation}) to registerInstrumentations({instrumentations: [fooInstrumentation]})
      • passing Instrumentation classes to registerInstrumentations() is now not possible anymore.
• feat(sdk-node)!: simplify type of instrumentations option
  • Breaking changes:
    • replaces InstrumentationOptions with (Instrumentation | Instrumentation[])[]

🚀 (Enhancement)

• feat(instrumentation): apply unwrap before wrap in base class #4692
• 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
• refactor(instrumentation-xml-http-request): use exported strings for semantic attributes. #4681

🐛 (Bug Fix)

• fix(instrumentation): Update import-in-the-middle to fix numerous bugs #4745 @timfish

📚 (Refine Doc)

• docs(instrumentation): better docs for supportedVersions option #4693 @blumamir
• docs: align all supported versions to a common format #4696 @blumamir
• refactor(examples): use new exported string constants for semconv in experimental/examples/opencensus-shim #4763 @Zen-cronic

[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.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.81%. Comparing base (ecc88a3) to head (6554b25).
Report is 21 commits behind head on main.

❗ Current head 6554b25 differs from pull request most recent head 8da8fd4

Please upload reports for the commit 8da8fd4 to get more accurate results.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4677      +/-   ##
==========================================
- Coverage   91.04%   89.81%   -1.24%     
==========================================
  Files          89      147      +58     
  Lines        1954     3220    +1266     
  Branches      416      699     +283     
==========================================
+ Hits         1779     2892    +1113     
- Misses        175      328     +153     

see 98 files with indirect coverage changes

[pichlermarc]

@open-telemetry/javascript-approvers this release PR is now unblocked:

• dd-trace is updated
• feat(sdk-trace-node): support xray propagator #4602 has been rolled back (see Revert "feat(sdk-trace-node): support xray propagator (#4602)" #4727)

[pichlermarc]

There's an unreleased bug on main (missing dependency), fixed by #4732.
Other than that there's nothing blocking this release anymore.

[trentm]

• feat(propagator-aws-xray-lambda): add AWS Xray Lambda propagator 4554

@pichlermarc Is there a need/reason to avoid publishing this propagator from the core repo? I suppose it is fine. It can be moved and published from contrib repo later.

[trentm]

Merge conflicts to sort out, and I asked a Q above about the new AWS Xray Lambda propagator package.

[pichlermarc]

• feat(propagator-aws-xray-lambda): add AWS Xray Lambda propagator 4554

@pichlermarc Is there a need/reason to avoid publishing this propagator from the core repo? I suppose it is fine. It can be moved and published from contrib repo later.

It's not spec compliant but I think it's fine for now. We can move it to contrib at any time and be spec compliant again.