chore: rename sdks to better represent what they are [#2146]

[vmarchaud]

As discussed in the SIG i believe this is the last item before making a RC release for tracing's SDK.
When this will be merged, we'll need to:

• make a PR on contrib to update all dependencies
• release contrib
• deprecate old packages on NPM (i don't have the right to do this right now)
• State that the 0.24 release is the RC for the tracing SDKs ?

Fixes #2146

[codecov]

Codecov Report

Merging #2340 (c26d49d) into main (4e78e4b) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main    #2340   +/-   ##
=======================================
  Coverage   92.78%   92.78%           
=======================================
  Files         145      145           
  Lines        5226     5226           
  Branches     1071     1071           
=======================================
  Hits         4849     4849           
  Misses        377      377           

Impacted Files	Coverage Δ
...ry-context-zone-peer-dep/src/ZoneContextManager.ts	85.18% <ø> (ø)
.../opentelemetry-exporter-collector/src/transform.ts	88.69% <ø> (ø)
...lemetry-exporter-collector/src/transformMetrics.ts	95.71% <ø> (ø)
...ckages/opentelemetry-exporter-jaeger/src/jaeger.ts	90.90% <ø> (ø)
...ges/opentelemetry-exporter-jaeger/src/transform.ts	100.00% <ø> (ø)
...etry-exporter-prometheus/src/PrometheusExporter.ts	90.66% <ø> (ø)
...exporter-prometheus/src/PrometheusLabelsBatcher.ts	100.00% <ø> (ø)
...ry-exporter-prometheus/src/PrometheusSerializer.ts	98.18% <ø> (ø)
...ges/opentelemetry-exporter-zipkin/src/transform.ts	100.00% <ø> (ø)
...ckages/opentelemetry-exporter-zipkin/src/zipkin.ts	100.00% <ø> (ø)
... and 47 more

[Flarna]

Regarding RC. There are still some points open in instrumentation package which may require API changes if we want to fix them. Not sure if this should be done before RC or if it is ok to do this later.

#1989, #2257 and #2258

[vmarchaud]

Not sure if this should be done before RC or if it is ok to do this later.

About this @dyladan @obecny, how do we track what is left for SDK RC ?

[dyladan]

I would strongly recommend we handle changes like that before RC. There is no official tracker for RC right now, I'll create a project we can store issues in.

[dyladan]

With almost 300 files changed it's really hard to see what real concrete changes were made. Can you please provide a recap of which packages were renamed/created/deleted and what their new names are?

[vmarchaud]

With almost 300 files changed it's really hard to see what real concrete changes were made. Can you please provide a recap of which packages were renamed/created/deleted and what their new names are?

packages renamed:

• @opentelemetry/tracing -> @opentelemetry/sdk-base-tracing
• @opentelemetry/node -> @opentelemetry/sdk-node-tracing
• @opentelemetry/web -> @opentelemetry/sdk-web-tracing
• @opentelemetry/metrics -> @opentelemetry/sdk-base-metrics
• @opentelemetry/node-sdk -> @opentelemetry/sdk-node-all

[vmarchaud]

ping @dyladan @obecny

[dyladan]

What becomes the recommended entrypoint? When we have an end user, which package do we tell them to install by default? sdk-node/web-all?

[vmarchaud]

What becomes the recommended entrypoint? When we have an end user, which package do we tell them to install by default? sdk-node/web-all?

Well it depend if we want them to install all signals sdks, but yeah i would say both sdk-node-all and sdk-web-all

[dyladan]

I'm not sure we need sdk- in the name. It seems to me like it is just additional typing for little benefit. I am worried that if we have too many packages like this it will be confusing for end-users. I think the name tracing was pretty unambiguous. node, web, and node-sdk were probably a little bit misleading and could do with some clarification, but I think we should be selling node and web as the only entrypoints and everything else should be considered an internal package. Unless they have specific requirements or concerns, users should only have to install api and node or web depending on platform.

[vmarchaud]

I'm not sure we need sdk- in the name. It seems to me like it is just additional typing for little benefit. I am worried that if we have too many packages like this it will be confusing for end-users. I think the name tracing was pretty unambiguous. node, web, and node-sdk were probably a little bit misleading and could do with some clarification, but I think we should be selling node and web as the only entrypoints and everything else should be considered an internal package. Unless they have specific requirements or concerns, users should only have to install api and node or web depending on platform.

So if i understand correctly you are suggesting:

• @opentelemetry/tracing -> @opentelemetry/base-tracing
• @opentelemetry/node -> @opentelemetry/node-tracing
• @opentelemetry/web -> @opentelemetry/web-tracing
• @opentelemetry/metrics -> @opentelemetry/base-metrics
• @opentelemetry/node-sdk -> @opentelemetry/node

[obecny]

My 3 cents:

@opentelemetry/tracing - no changes
@opentelemetry/node -> @opentelemetry/tracing-node
@opentelemetry/web -> @opentelemetry/tracing-web

@opentelemetry/metrics - no changes
@opentelemetry/api-metrics -> @opentelemetry/metrics-api

@opentelemetry-sdk-node - no changes

[obecny]

strange errors failures, seems like something hasn't been yet changed probably ? missing upgrading guidelines

[dyladan]

@vmarchaud whats the status on this?

[vmarchaud]

@dyladan I'm trying to find time to finish the PR, i hope later today !

[vmarchaud]

PTAL again @open-telemetry/javascript-maintainers @open-telemetry/javascript-approvers

[obecny]

lgtm