Make SDK update prompt less noisy/more meaningful

[HazAT]

Problem Statement

The problem is that we prompt our users to upgrade their SDK version for every update we ship for SDKs.
We ship a lot of updates so that the prompt could be perceived as unimportant but it shouldn't be.
Also, upgrading without a reason also doesn't make sense; we don't do it, and why should others?

Solution Brainstorm

I am already going into proposals to make these prompts more meaningful.
(Consider it as a suggestion and not how we actually should solve it)

We add a manually maintained entry in the release registry for certain important SDK updates:
https://github.com/getsentry/sentry-release-registry/blob/master/packages/npm/%40sentry/browser/7.8.1.json#L7
To start, we can just document how to do it, and SDK developers should be aware of it. We don't need a complex system around it since it anyway shouldn't happen that often.

e.g.:

"update_text": "{version} contains important security updates"

"update_text": "{version} support new Dynamic Sampling feature, read more: {link}"

We only prompt users if such a text exists and their used version is smaller.
Once dismissed, we never prompt the user again until we ship a new version that again contains update_text

Edit:
ref
https://github.com/getsentry/sentry/blob/0a8a328d9af5fb01217f037d502b6377761ac6de/static/app/components/globalSdkUpdateAlert.tsx

[getsentry-release]

Routing to @getsentry/team-web-sdk-frontend for triage. ⏲️

[getsentry-release]

Routing to @getsentry/team-web-sdk-backend for triage. ⏲️

[getsentry-release]

Routing to @getsentry/team-web-sdk-backend for triage. ⏲️

[silent1mezzo]

👍 love this

[AbhiPrasad]

Another addendum to make this more product driven! Instead of blanket just displaying this update message on every page, we specifically ask for upgrades to unlock certain features in the SDK. For example, we ask folks to upgrade to an SDK that has DS support. We can do this by (finally) introducing an SDK feature list as per getsentry/sentry-release-registry#39. We would introduce a features.json that lives at the root of every SDK repo to make this happen.

We can start off by making update_text live in that feature file, and that's what craft would read to update the release registry accordingly. This leaves us room to expand into a proper SDK feature list.

[jeremybourque]

I love the update text idea too! Couple of suggestions...

• If a user doesn't dismiss the update text after we've shown it to them a few times can we auto-dismiss it for that user so it doesn't linger in the UI needlessly?
• If a new update text appears and the user hasn't installed previous updates, could roll up all the update texts after their current version, or at least the most recent ones, so they know what they're getting?