we can remove the features and code directly instead of deprecating them first.

keep in mind we still need a semver-major (aka minor version as we are [perpetually] 0.X)

Relay (which uses the sentry-types crate)

I’m surprised it does. Do you know what for exactly?

Probably the more interesting thing to test would be sentry-cli, which uses the SDK to submit demo/test events.

we can remove the features and code directly instead of deprecating them first.

keep in mind we still need a semver-major (aka minor version as we are [perpetually] 0.X)

Sure. I then changed my mind and I was thinking to deprecate the feature first and that's why I turned this PR into a draft.

Relay (which uses the sentry-types crate)

I’m surprised it does. Do you know what for exactly?

It's only used here: https://github.com/getsentry/relay/blob/3dfdba91c534877f4623a76e6dcd187a4caf2c00/relay-common/src/lib.rs#L14

Probably the more interesting thing to test would be sentry-cli, which uses the SDK to submit demo/test events.

Good catch.
Indeed, the CLI still has some metrics APIs with a deprecation warning, saying that they will be removed in the next major.

With this information, I would just add deprecation warnings to the SDK, then wait for the next sentry-cli major to completely remove the code and crate feature from the SDK.
This way they will still be able to use the latest version of the SDK.

With this information, I would just add deprecation warnings to the SDK, then wait for the next sentry-cli major to completely remove the code and crate feature from the SDK.

TBH, I consider these usages within sentry-cli as really bad. The SDK is not made for that usecase, and sentry-cli should probably use some raw envelope items or some other way, instead of using the SDK "as an SDK" to do this.

sentry-cli will turn their metrics APIs into noops when they are going to update the SDK, so we can safely merge this.