OpenTelemetry JavaScript SDK 2.0 Support

[gidich]

• Package Names: @azure/monitor-opentelemetry-exporter (1.0.0-beta.29), @azure/opentelemetry-instrumentation-azure-sdk(1.0.0-beta.9 and 8), @azure/monitor-opentelemetry (1.9.0), @azure/functions-opentelemetry-instrumentation (0.1.0)
• Package Version: (see above)
• Operating system:
• nodejs
  • version: v20.6.0+
• browser
  • name/version: n/a
• typescript
  • version: v5.0.4+
• Is the bug related to documentation in
  • README.md
  • source code documentation
  • SDK API docs on https://learn.microsoft.com

Describe the bug
OpenTelemetry recently upgraded to v2.0, looking for details of plans to upgrade all impacted libraries to align with the new version.

• When would one expect the move to v2.0 dependencies to arrive? ( 1 month, 3 months, 6 months + )
• Will support for v1.x-based libraries immediately cease once the support for v2.x begins?

OpenTelemetry Announcement
https://opentelemetry.io/blog/2025/otel-js-sdk-2-0/

[heruwala]

following

[JacksonWeber]

@gidich This is being considered in our planning. I wouldn't expect this to arrive for at least six months. Ideally, we'll support only v2.x once it's generally adopted, but this stance could change. I'll keep this thread updated and thank you for the question.

[timtucker-dte]

@gidich Ideally, we'll support only v2.x once it's generally adopted, but this stance could change.

Can you clarify this a little? Who are you waiting for to "generally adopt" OTEL 2.0 / what's the purpose behind waiting?

Most of the users of these SDKs will only be adopting it once Microsoft starts supporting it, which seems like a bit of a chicken and egg situation.

If Microsoft is promoting OpenTelemetry over native App Insights integration, but isn't confident in the direction that OpenTelemetry is headed, why should we as customers have faith in the direction that Microsoft is heading?

If Microsoft is committed to supporting OpenTelemetry and believes they're headed in the right direction, keeping pace with their spec updates seems like a no-brainer -- otherwise you're risk running into a situation where OTEL 3.0 contracts are out before OTEL 2.0 support is ready and people are being asked to make breaking changes in their code knowing that they're already out of date (as we've seen with things like support for Node LTS versions in Azure).

Delaying also means depriving the OpenTelemetry project of feedback from real-world use cases that could be helping to drive out future updates to specs. At which point an eventual 3.0 spec is likely to cater more to the customers of other vendors for logging that adopted 2.0 more quickly than the needs of Azure SDK users.