Self-Hosted Sentry Switching to CalVer

Since the beginning, Sentry has adopted SemVer (semantic versioning) for all of its open source releases — major versions indicated breaking, backward-incompatible changes; minor versions meant new features, and patch releases were bug fixes only. This process worked fine for a long time.

As the open source project evolved and grew into Sentry.io – our SaaS offering – the development team switched to a continuous delivery model. Continuous delivery means shipping every new change to Sentry.io shortly after it lands on our main Git branch. At the same time, we continued to cut open source releases using SemVer. This new model inevitably created a mismatch between the hosted version and open source versions. It wasn’t long until named SemVer releases started to lag significantly behind Sentry.io, sometimes by as much as six months.

Sentry v10 and continuous releases for self-hosted

Our last major open source release of Sentry, version 10, was an example of a release with “breaking changes.” It removed support for all databases except for Postgres, and required new services to run in production (Snuba, Symbolicator) alongside the main Sentry server. We also settled on Docker as the preferred means for deploys.

More importantly, Sentry 10 has been the last official “tagged” release of Sentry. To avoid the ongoing lag between Sentry.io and self-hosted releases, we replaced manual SemVer releases with Docker images for every new commit to our main Git repository. Having runnable Docker images for every new commit meant you could run the same version hosted on Sentry.io in lock-step. Great, right?

Not so fast. Deploying and running multiple services (Sentry, Snuba, Relay, and Symbolicator introduced a new type of version coordination needed by the point-in-time nature of self-hosted deploys. Not to mention, it’s not reasonable to ask on-premise users to coordinate rolling data migrations between two arbitrary SHAs, especially with little in the way of guides or documentation.

Turns out we need versions, but not necessarily semantic versions.

Enter CalVer: the versioning schema we need

CalVer is essentially a timestamp – the same timestamp – attached to all related projects with a patch release version for emergencies. The “major” version becomes the year, and the “minor” version becomes the month while the “patch” version stays to serve the same purpose: bearing hotfixes.

Major projects like VS Code, Ubuntu, and Docker also adopt this model. CalVer aligns well with how we develop and use Sentry. More importantly, it helps us and our community to refer to a specific release for the whole project when we need to.

Going forward we’ll be shipping updates on a monthly cadence — hopefully, this release plan is predictable and decreases the overhead of upgrading.

Introducing Sentry v20.6.0

Without further ado, I present to you the next milestone of Sentry: v20.6.0. In this release you’ll find the following:

• Discover v2: unlock more in-depth insights into the health of your entire system and answer critical business questions

• Sentry Native: debug native applications faster with the power of alerts, context, and root-cause analysis.

• Release Health: Monitor the health of releases by observing user adoption, usage of the application, percentage of crashes, and session data.

• Many performance improvements and fixes across the board

You can find the full list of changes for this release here.

We hope you enjoy this new version, and the approach we’re taking with self-hosted releases going forward. If you have any feedback, questions about the new versioning schema, or questions about v20.6.0 specifically, please talk to us at the forums.

See you next month!