Setting up releases in Bugsink allows for two key features: the ability to resolve issues by release and to gain better visibility into which releases are affected by specific issues. Properly configuring releases ensures your team can track, manage, and resolve issues more efficiently.
To set up releases in Bugsink, you’ll need to configure your SDK to provide a release identifier. This can be done by directly setting the release in the SDK or using environment variables. Below is an example for Python:
import sentry_sdk
sentry_sdk.init(
# ...
# Set a human-readable release identifier.
release="1.0.0",
)
Rather than hard-code 1.0.0, you’ll want to set the release dynamically based on
your build process, in a way that works for your project. If you don’t, the Sentry
SDK will try to infer the release from various environment variables or the latest
Git commit SHA.
Note: This applies to the Python SDK. Specific instructions may vary depending on the language or platform you are using.
We strongly recommend using semver (semantic versioning). It ensures:
Any non-semver releases (among which commit hashes) will simply be ordered by date.
A few further restrictions apply to release names:
/), or backslashes (\\). (period), .. (double period), or a space (Package names are ignored (i.e. any text before “@”, if it is present). This is
simply for compatibility with Sentry setups. Bugsink tracks releases per project, so
package names are not needed.
Bugsink smoothly handles transitions between versioning schemes. For example, if you switch from using commit hashes to semver, Bugsink ensures earlier releases are correctly ordered relative to the newer ones. You can even go back to a non-semver scheme, although this is not recommended.
Once releases are set up in Bugsink, they help you manage and resolve issues across different versions. Bugsink tracks which releases are affected by specific issues, and shows this information in the issue and event details.
Bugsink supports marking issues as resolved by a specific release. This ensures that an issue is only marked as resolved in the versions where it no longer occurs, and that it is not marked as a regression when events from earlier releases are received.
Resolved in next release: This is the most common flow: you fix an issue in your codebase and immediately mark it as resolved in the next release. This marks the issue as resolved in Bugsink (such that it no longer appears in the open issue list), but Bugsink understands that the issue is still open in the current release. Once the next release is available, Bugsink will automatically mark the issue as resolved by that specific release. New events will only be marked as regressions if they occur in that release or later.
Resolve in latest release: If an issue is resolved in the latest (actually released) release, you can mark it as such. This is useful if you didn’t immediately mark the issue as “resolved in next release” when you actually fixed it in the codebase, i.e. when you’re revisiting old issues after the release has been made.
If you haven’t set up releases in Bugsink, you can still resolve issues, but the resolution will apply to all releases. In this flow it is not really possible to pro-actively mark an issue as resolved in a future release, because it would likely be marked as a regression soon after.
In the current version of Bugsink, it is not yet possible to set up releases directly in the UI or the CLI. This is a feature we are working on, and we expect to release it soon. In the meantime, releases are always automatically inferred from events that have a release identifier attached.