Sentry releases: notify before deploy, resolve in release

# Sentry releases: notify before deploy, resolve in release

## Set the identifier in the SDK

```python
sentry_sdk.init(release="myapp@1.2.3")
```

Or skip it: the SDK reads the `SENTRY_RELEASE` env var, else infers the git commit SHA. A human-readable `name@version` beats a bare SHA when you are scanning the releases page. Whatever you choose, it must be identical across every service and the CI upload step, or Sentry treats them as different releases.

## Notify from CI before deploy

```
sentry-cli releases -o [your org] new -p [your project] myapp@1.2.3
sentry-cli releases -o [your org] -p [your project] set-commits myapp@1.2.3 --auto
sentry-cli releases -o [your org] -p [your project] deploys myapp@1.2.3 new -e production
```

Note the scoping: org goes on the `releases` command, project on the subcommand. `set-commits --auto` associates the commit range so Sentry can predict suspect commits and authors. If you skip this, Sentry still auto-creates a release entity when the first event arrives, but with no commits and no deploy record.

## What releases buy you

- New-issue and regression detection per release on the releases page, with crash-free user and session percentages.
- Suspect commits: Sentry predicts which commit caused an issue and who likely owns it.
- Resolve in release: on an issue, Resolve > Resolved in the next release (or current). With semver, Sentry unresolves the issue if it reappears in a later version; without semver it compares release creation dates.

## Verification

After a deploy, open the Releases page and confirm the version appears with commits and the deploy marker. If events carry a release that never shows, the identifier differs between SDK and CLI (trailing whitespace and `v` prefixes are the usual culprits).