Releases

Tag your events with a release version so you can track when a bug was introduced and whether it has been fixed.

Setting the release#

Laravel#

SENTRY_RELEASE=1.4.2

Or generate it from git:

SENTRY_RELEASE="${git rev-parse --short HEAD}"

Or in config/sentry.php:

'release' => env('SENTRY_RELEASE'),

JavaScript#

Sentry.init({
  dsn: 'https://your-key@your-hostname.tindra.sh/1',
  release: '1.4.2',
});

Use your build tool to inject the version at build time:

// vite.config.js
define: {
  __APP_VERSION__: JSON.stringify(process.env.npm_package_version),
}

Sentry.init({
  dsn: '...',
  release: __APP_VERSION__,
});

Python#

sentry_sdk.init(
    dsn="...",
    release="1.4.2",
)

What releases give you#

• See which release first introduced an issue under First seen in on the issue detail page.
• Filter the issues list by release to see what broke in a specific deploy.
• Resolved issues automatically re-open if the same error appears in a later release.

Releases list#

Navigate to Releases in the sidebar to see a list of all releases Tindra has seen events for. Click a release to see the issues associated with it.

Naming convention#

Use something you can trace back to your deployment. Good options:

• Semantic version: 1.4.2
• Git SHA: a3f9b21
• Git tag: v2024.11.15

Avoid spaces. Keep it short and consistent across services.