chore: release proposal v1.0.1

[dyladan]

🚀 (Enhancement)

• Other
  • #2465 fix: prefer globalThis instead of window to support webworkers (@legendecas)
• opentelemetry-semantic-conventions
  • #2532 feat(@opentelemetry/semantic-conventions): change enum to object literals (@echoontheway)
  • #2528 feat: upgrade semantic-conventions to latest v1.7.0 spec (@weyert)
• opentelemetry-core, opentelemetry-sdk-trace-base
  • #2484 feat: new merge function (@obecny)

🐛 (Bug Fix)

• Other
  • #2581 feat: lazy initialization of the gzip stream (@fungiboletus)
  • #2584 fix: fixing compatibility versions for detectors (@obecny)
  • #2560 fix(core): support regex global flag in urlMatches (@moander)
• opentelemetry-exporter-zipkin
  • #2519 fix(exporter-zipkin): correct status tags names (@t2t2)

📚 (Refine Doc)

• opentelemetry-core
  • #2604 Docs: Document the HrTime format (@JamesJHPark)
• Other
  • #2576 docs(instrumentation): update links in the Readme (@OlivierAlbertini)
  • #2600 docs: fix URLs in README post-experimental move (@arbourd)
  • #2579 doc: Move upgrade propagator notes to correct section (@NathanielRN)
  • #2568 chore(doc): update matrix with contrib version for 1.0 core (@vmarchaud)
  • #2555 docs: expose existing comments (@moander)
  • #2493 chore: remove getting started and link to documentation. (@svrnm)

🏠 (Internal)

• opentelemetry-sdk-trace-base, opentelemetry-sdk-trace-node, opentelemetry-sdk-trace-web
  • #2607 chore: update npm badge image links (@legendecas)
• Other
  • #2570 chore: adding selenium tests with browserstack (@obecny)
  • #2522 chore: cleanup setting config in instrumentations (@Flarna)
  • #2541 chore: slim font size for section title in PR template (@legendecas)
  • #2509 chore: expand pull request template with action items (@pragmaticivan)
  • #2488 chore: inline sources in source maps (@dyladan)
• opentelemetry-context-async-hooks, opentelemetry-context-zone-peer-dep, opentelemetry-core, opentelemetry-exporter-jaeger, opentelemetry-exporter-zipkin, opentelemetry-propagator-b3, opentelemetry-propagator-jaeger, opentelemetry-resources, opentelemetry-sdk-trace-base, opentelemetry-sdk-trace-node, opentelemetry-sdk-trace-web, opentelemetry-shim-opentracing
  • #2531 chore(deps): pin minor API version (@Flarna)
• opentelemetry-core
  • #2520 chore(deps): remove unused semver (@mhennoch)

Committers: 20

• (Eliseo) Nathaniel Ruiz Nowell (@NathanielRN)
• Antoine Pultier (@fungiboletus)
• Bartlomiej Obecny (@obecny)
• Daniel Dyla (@dyladan)
• Dylan Arbour (@arbourd)
• Georg Pirklbauer (@pirgeo)
• Gerhard Stöbich (@Flarna)
• Ivan Santos (@pragmaticivan)
• Jack (@mothershipper)
• James (@JamesJHPark)
• MartenH (@mhennoch)
• Olivier Albertini (@OlivierAlbertini)
• Severin Neumann (@svrnm)
• Valentin Marchaud (@vmarchaud)
• Weyert de Boer (@weyert)
• William Armiros (@willarmiros)
• @echoontheway
• legendecas (@legendecas)
• moander (@moander)
• t2t2 (@t2t2)

[codecov]

Codecov Report

Merging #2609 (fe2eb52) into main (61cfbfe) will decrease coverage by 0.04%.
The diff coverage is n/a.

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

@@            Coverage Diff             @@
##             main    #2609      +/-   ##
==========================================
- Coverage   93.04%   93.00%   -0.05%     
==========================================
  Files         138      138              
  Lines        5093     5092       -1     
  Branches     1096     1095       -1     
==========================================
- Hits         4739     4736       -3     
- Misses        354      356       +2     

Impacted Files	Coverage Δ
...entelemetry-instrumentation/src/instrumentation.ts	70.37% <0.00%> (-7.41%)	⬇️
...entelemetry-instrumentation/src/autoLoaderUtils.ts	91.66% <0.00%> (-0.34%)	⬇️

[obecny]

lgtm, any chance to release experimental packages too ?

[obecny]

hmm I see in description my PR - changes in experimental only which is listed here but not released, why is that ?
this one -> #2584

[vmarchaud]

hmm I see in description my PR - changes in experimental only which is listed here but not released, why is that ?

I believe because we don't release experimental at the same time of core packages ?

[dyladan]

hmm I see in description my PR - changes in experimental only which is listed here but not released, why is that ? this one -> #2584

The automated changelog tool isn't smart enough to know the difference between experimental and stable PRs so I had to do my best to remove the experimental ones and just missed one. I'll remove it.

hmm I see in description my PR - changes in experimental only which is listed here but not released, why is that ?

I believe because we don't release experimental at the same time of core packages ?

I was thinking about this. What would you think of a single PR which released experimental and stable? Then the changelog generation is a little easier and we don't have to go through the PR process twice for a single release?

[vmarchaud]

I was thinking about this. What would you think of a single PR which released experimental and stable? Then the changelog generation is a little easier and we don't have to go through the PR process twice for a single release?

I checked on the other PR but the experimental will not depend on latest core if we do this, that means some experimental pkgs won't have latest bug fixes. I think its better to split them, WDYT ?

[dyladan]

I was thinking about this. What would you think of a single PR which released experimental and stable? Then the changelog generation is a little easier and we don't have to go through the PR process twice for a single release?

I checked on the other PR but the experimental will not depend on latest core if we do this, that means some experimental pkgs won't have latest bug fixes. I think its better to split them, WDYT ?

I can update the core deps in this PR. It just means I have to run the release command for core before experimental which I would have had to do anyway so it's no different.

[dyladan]

I was thinking about this. What would you think of a single PR which released experimental and stable? Then the changelog generation is a little easier and we don't have to go through the PR process twice for a single release?

I checked on the other PR but the experimental will not depend on latest core if we do this, that means some experimental pkgs won't have latest bug fixes. I think its better to split them, WDYT ?

I updated the other PR. Take a look there. if you still have doubts we can reopen this.