1.0.0-rc.1 proposal

[dyladan]

💥 Breaking Change

• #55 chore: move baggage methods in propagation namespace (@vmarchaud)
• #65 chore: remove suppress instrumentation (@dyladan)
• #60 chore: removing timed event (@obecny)
• #58 chore: use spancontext for link (@dyladan)
• #47 chore: move span method for context in trace API Consider moving setSpan()/getSpan() to its related subsection #40 (@vmarchaud)
• #45 chore: rename span#context() to span#spanContext (@dyladan)
• #43 chore: renaming noop span to non recording span (@obecny)
• #32 feat!: return boolean success value from setGlobalXXX methods (@dyladan)

🚀 Enhancement

• #54 feat: add tracer.startActiveSpan() (@naseemkullah)
• #58 chore: use spancontext for link (@dyladan)
• #51 feat: add function to wrap SpanContext in NonRecordingSpan [spec] add trace#wrapSpanContext #49 (@dyladan)

📝 Documentation

• #64 chore: document the reason for symbol.for (@dyladan)
• #44 chore: updating readme headline and fixing links (@obecny)

Committers: 6

• Bartlomiej Obecny (@obecny)
• Daniel Dyla (@dyladan)
• Gerhard Stöbich (@Flarna)
• Naseem (@naseemkullah)
• Valentin Marchaud (@vmarchaud)
• t2t2 (@t2t2)

[codecov]

Codecov Report

Merging #70 (0e99421) into main (20f3bfc) will decrease coverage by 0.09%.
The diff coverage is 100.00%.

❗ Current head 0e99421 differs from pull request most recent head dbf2723. Consider uploading reports for the commit dbf2723 to get more accurate results

@@            Coverage Diff             @@
##             main      #70      +/-   ##
==========================================
- Coverage   94.99%   94.89%   -0.10%     
==========================================
  Files          41       35       -6     
  Lines         559      549      -10     
  Branches       94       93       -1     
==========================================
- Hits          531      521      -10     
  Misses         28       28              

Impacted Files	Coverage Δ
src/version.ts	100.00% <100.00%> (ø)
karma.base.js
src/platform/browser/globalThis.ts
webpack.node-polyfills.js
src/platform/browser/index.ts
karma.conf.js
karma.webpack.js

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 20f3bfc...dbf2723. Read the comment docs.

[Flarna]

I think we should either close or merge #46 first

[obecny]

this is missing the review and I think should be a part of this release -> #62

[dyladan]

@Flarna wants #46 to be merged first. @obecny wants core changes to be made in core before #46 can merge. Those core changes depend on unreleased API changes (we need wrapSpan to create noop spans without the noop tracer.

I fear we are in a dependency loop here. @Flarna @obecny how do you think we should resolve this ordering issue? My plan was to release rc.1 now, make the core changes, release core, then release rc.2 with noops removed.

[obecny]

@Flarna wants #46 to be merged first. @obecny wants core changes to be made in core before #46 can merge. Those core changes depend on unreleased API changes (we need wrapSpan to create noop spans without the noop tracer.

I fear we are in a dependency loop here. @Flarna @obecny how do you think we should resolve this ordering issue? My plan was to release rc.1 now, make the core changes, release core, then release rc.2 with noops removed.

If we merge #46 we will have to do some work on core and contrib before people can use it and before we can release core and contrib. What I propose is to wait with merging #46 until it is done first in core and contrib so we don't block ourselves and that we have api that cannot be used with anything. This way we can do release on core and contrib quicker, and we are not blocked. We can do next rc as soon as all necessary changes are done in core and contrib. You merge #46 now and you will have api you cant use with anything for days.

unless I'm missing something so pls correct me :)

[dyladan]

@Flarna wants #46 to be merged first. @obecny wants core changes to be made in core before #46 can merge. Those core changes depend on unreleased API changes (we need wrapSpan to create noop spans without the noop tracer.
I fear we are in a dependency loop here. @Flarna @obecny how do you think we should resolve this ordering issue? My plan was to release rc.1 now, make the core changes, release core, then release rc.2 with noops removed.

If we merge #46 we will have to do some work on core and contrib before people can use it and before we can release core and contrib. What I propose is to wait with merging #46 until it is done first in core and contrib so we don't block ourselves and that we have api that cannot be used with anything. This way we can do release on core and contrib quicker, and we are not blocked. We can do next rc as soon as all necessary changes are done in core and contrib. You merge #46 now and you will have api you cant use with anything for days.

unless I'm missing something so pls correct me :)

I'm fine with this, but I think there might already be some breaks that will need to be implemented in core anyways so it will be blocked no matter what. Holding off on #46 is fine as long as we can get these done quickly. If we merge this now, I'll create a PR to bump API in core immediately so we can make the changes required for #46

[dyladan]

any opinion here @Flarna?

[obecny]

I'm fine with this, but I think there might already be some breaks that will need to be implemented in core anyways so it will be blocked no matter what. Holding off on #46 is fine as long as we can get these done quickly. If we merge this now, I'll create a PR to bump API in core immediately so we can make the changes required for #46

If I understand correctly, after you do a new rc api release, we can do next release for core and contrib immediately, nothing needs to be changed except some renaming or using different namespace. All other changes has been done already right ?

[dyladan]

I'm fine with this, but I think there might already be some breaks that will need to be implemented in core anyways so it will be blocked no matter what. Holding off on #46 is fine as long as we can get these done quickly. If we merge this now, I'll create a PR to bump API in core immediately so we can make the changes required for #46

If I understand correctly, after you do a new rc api release, we can do next release for core and contrib immediately, nothing needs to be changed except some renaming or using different namespace. All other changes has been done already right ?

I think most but I'm not 100% sure.

[naseemkullah]

Will #54 be included as well since it has been merged?

[dyladan]

Will #54 be included as well since it has been merged?

yes

[dyladan]

reviews pls :)

[naseemkullah]

apart from #54 missing in changelog lgtm

[Flarna]

my intention was to reduce the number of breaking releases as they are usually not that nice for consumers.
But if rc.1 + core and contrib now and then more or less immediatelly rc.2 + core and contrib is the way to go it's fine for me.

[Flarna]

I think the readme should be updated (https://github.com/open-telemetry/opentelemetry-js-api/blob/main/README.md#100-rc0-to-x).

And I assume also the version in package.json needs an update. Or is this done automatically?

[dyladan]

OK. Waiting for @obecny because I think all maintainers should agree

[obecny]

OK. Waiting for @obecny because I think all maintainers should agree

what about this one ?
#70 (comment)

[obecny]

lgtm

[dyladan]

Tests and lint are passing locally. Is it ok if we merge and release this without the successful actions?