Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

meta(changelog): Update changelog for v7.95.0 #10298

Merged
merged 17 commits into from
Jan 23, 2024
Merged

Conversation

mydea
Copy link
Member

@mydea mydea commented Jan 23, 2024

Just 5 more to go to 7.💯 !

mydea and others added 16 commits January 19, 2024 09:39
…ns()` (#10243)

The current implementation has two problems:

1. It is weird that you can accidentally mutate the default integrations
of another package
2. We sometimes have logic-based default integrations - e.g. adding an
integration only if tracing is enabled, or similar. This means that
either we have to add some logic in the _upstream_ SDK to ensure this is
still added even if downstream SDKs overwrite default integrations, or
we need to duplicate the logic in the _downstream_ SDKs. With this new
method, we can instead centralize this, and downstream SDKs simply need
to call upstream `getDefaultIntegrations(options)`.
The usage of this was not really working well to begin with, and even
worse with the new functional integrations. Because if the user adds the
integration themselves (e.g. `integrations: [new RewriteFrames()]`), it
will not actually get the correct iteratee at all.

Overall it is much cleaner anyhow to just fork the integrations properly
and use them instead of the default one - then we can rely on the
standard behavior of merging integrations etc.

We need to do the same for basically all usages of
`addOrUpdateIntegration`, as that actually does not work at all anymore
with the functional integrations 😬 (and in many instances never really
worked properly if users passed in a custom integration themselves).

Co-authored-by: Abhijeet Prasad <[email protected]>
We should wait for
#10243 to merge this,
as otherwise we'll get a deprecation/eslint error there.
[Gitflow] Merge master into develop
There have been tries to do this before, but let's see how things stand
today...
Deprecate the `Span.parentSpanId` field on the interface and class. 

This required only a couple of code replacements and a bunch of test
adjustments. Also went ahead and changed the integration test event type
in the tests I was modifying.
…bute (#10260)

Deprecate the `Span.origin` field on the class and the
interface. It will be replaced in v8 by the semantic `sentry.op`
attribute.
We should think about moving the wasm integration into `@sentry/browser`
and removing `@sentry/wasm` all together. What do you think?
By using functional integrations in #10230, we started importing from
`@sentry/core` in the WASM integration. However, we didn't register
`@sentry/core` as a dependency, making rollup bundle core into the
package output. This changed the `build/npm` directory structure, making
our entry points in `package.json` invalid.

This PR fixes things by simply registering core as a dependency of wasm.
If we move WASM to core (which I strongly think we should do), we'll be
able to get rid of this again.
… API (#10085)

Move `parameterize` function to core, export it to upstream packages via browser and node.
Instead, users should use the new functional styles.

Note that we'll probably actually un-deprecate `Replay` in some form in
v8, as we'll be keeping the class around there for sure (as there is a
lot of logic in there...). But users should not use it, so deprecating
this now!

While at it, I also deprecated the old `InitSentryForEmber` method in
favor of `init()`.

It's slightly unfortunate that I missed this, but we probably shouldn't
have exposed `ReplayCanvas` as a class anymore at all 😬 maybe we wait
before we document this etc. until we merged the functional style. cc
@billyvg
…OrUpdateIntegration` (#10263)

This updates the last usage of `addOrUpdateIntegration` and deprecates
it.
Adds ability to configure all border radiuses on feedback widget

Closes #10256
…nt` (#10296)

Currently, you can use `Sentry.getClient() !== undefined` to check if
Sentry was initialized. In v8, we want to change this so that this
_always_ returns a client (possibly a Noop client), so this check will
not work anymore there. Instead, we can provide a new util that does
this explicitly, where we can control what it checks under the hood.
As per
https://developer.mozilla.org/en-US/docs/Web/API/PerformanceResourceTiming/responseStart,
`responseStart` can be 0 if the request is coming straight from the
cache. This might lead us to calculate a negative ttfb.

To account for these scenarios, use `Math.max` to make sure we always
set to 0 in the case of a negative value.
@mydea mydea self-assigned this Jan 23, 2024
CHANGELOG.md Show resolved Hide resolved
Copy link
Member

@Lms24 Lms24 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

5️⃣

Copy link
Contributor

github-actions bot commented Jan 23, 2024

size-limit report 📦

Path Size
@sentry/browser (incl. Tracing, Replay, Feedback) - Webpack (gzipped) 77.79 KB (+0.03% 🔺)
@sentry/browser (incl. Tracing, Replay) - Webpack (gzipped) 68.96 KB (+0.03% 🔺)
@sentry/browser (incl. Tracing, Replay with Canvas) - Webpack (gzipped) 72.85 KB (+0.03% 🔺)
@sentry/browser (incl. Tracing, Replay) - Webpack with treeshaking flags (gzipped) 62.6 KB (+0.03% 🔺)
@sentry/browser (incl. Tracing) - Webpack (gzipped) 32.97 KB (+0.05% 🔺)
@sentry/browser (incl. Feedback) - Webpack (gzipped) 31.24 KB (0%)
@sentry/browser (incl. sendFeedback) - Webpack (gzipped) 31.25 KB (0%)
@sentry/browser - Webpack (gzipped) 22.53 KB (0%)
@sentry/browser (incl. Tracing, Replay, Feedback) - ES6 CDN Bundle (gzipped) 75.46 KB (+0.03% 🔺)
@sentry/browser (incl. Tracing, Replay) - ES6 CDN Bundle (gzipped) 67.03 KB (+0.02% 🔺)
@sentry/browser (incl. Tracing) - ES6 CDN Bundle (gzipped) 32.85 KB (+0.05% 🔺)
@sentry/browser - ES6 CDN Bundle (gzipped) 24.36 KB (0%)
@sentry/browser (incl. Tracing, Replay) - ES6 CDN Bundle (minified & uncompressed) 211.12 KB (+0.02% 🔺)
@sentry/browser (incl. Tracing) - ES6 CDN Bundle (minified & uncompressed) 99.11 KB (+0.04% 🔺)
@sentry/browser - ES6 CDN Bundle (minified & uncompressed) 72.91 KB (0%)
@sentry/browser (incl. Tracing) - ES5 CDN Bundle (gzipped) 35.95 KB (+0.05% 🔺)
@sentry/react (incl. Tracing, Replay) - Webpack (gzipped) 69.37 KB (+0.03% 🔺)
@sentry/react - Webpack (gzipped) 22.58 KB (0%)
@sentry/nextjs Client (incl. Tracing, Replay) - Webpack (gzipped) 85.98 KB (+0.02% 🔺)
@sentry/nextjs Client - Webpack (gzipped) 50.27 KB (+0.03% 🔺)
@sentry-internal/feedback - Webpack (gzipped) 17.21 KB (0%)

@mydea mydea merged commit 9fcfd51 into master Jan 23, 2024
90 checks passed
@mydea mydea deleted the prepare-release/7.95.0 branch January 23, 2024 16:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants