Share on Twitter
Share on Facebook
Share on HackerNews
Share on LinkedIn

Releasing Open Source Sentry

While thousands of teams use hosted Sentry, tens of thousands are running it on-premise. Keeping on-premise deployments up-to-date with the latest error monitoring features and fixes is a priority for us. Fresh off our latest Sentry 8.6 release, we wanted to explain how we version Sentry and why it matters to you.

One of the benefits of using SaaS such as sentry.io or other closed-source projects within an organization is continuous deployment. Continuous deployment is the idea of deploying your product as soon as changes are committed so that your users can get features and fixes as soon as possible.

Running continuous deployments on-premise can be tedious. Shipping versioned software alleviates the pain of trying to guess what is in your package. Operations teams don’t want to update their Sentry install multiple times per day, and can rest easier knowing that if they identify a problem, they won’t be the only team in the world running that specific version.

Prior to 8.0, we had a very loose schedule when it came to cutting releases. Our last major release was 7.7.0, almost 7 months before 8.0 dropped. To ensure that we make the process of updating on-premise deployments of Sentry easier, starting with version 8.0, we began to follow an official release schedule.

The Schedule

Sentry is loosely versioned around semver, but in practice, this is much harder to adhere to compared to libraries. But what this means for us is:

  • Major versions (e.g. 8.0, or 9.0) are massive changes, such as a complete UI refresh or major infrastructure changes.
  • Minor versions (e.g., 8.1 or 8.2) contain things like database migrations, new features added, and changes in behavior. We cut minor versions from our master git branch and will release them on the 1st of each month.
  • Patch versions (e.g. 8.1.1 or 8.1.2) include critical bug fixes only. We will not introduce database migrations or change in behaviors in a patch release. Patch versions are cut periodically between our minor releases as critical bugs are addressed. There should be no risk in upgrading between patch releases.

Our new process brings Sentry’s open source compliance a step forward, and helps set expectations for our customers and users. The monthly schedule is more predictable and will help to establish a regular schedule of incremental updates, rather than massive, unpredictable releases. Additionally, operations teams will know what to expect when upgrading their instance, and will have an easier time scheduling and performing regular upgrades, cutting down on the number of stale deployments of Sentry in the wild.

The Process

Sentry is primarily a Python webserver, but it also includes a JavaScript application to drive our UI. For those that have dabbled into Python packaging and/or JavaScript packaging, there’s not a straightforward answer on how to ship a package including both. At the end of the day, we want our users to be burdened as little as possible with installation. And, of course, we use Sentry internally to make sure that burden in production remains low with JavaScript debugging and Python error tracking.

We have two different distributions, a Docker image on Docker Hub, and PyPI (the standard Python package index). When packaging our application, we pre-compile the JavaScript application, and bundle our documentation into the derived release artifact. Our setup.py does all of the bundling for us and removes the requirement for developers to install the JavaScript and documentation tool-chains.

Docker makes this much simpler, and we ultimately just install this PyPI package into an image and ship to Docker Hub. In fact, it is now our recommended way to install Sentry inside your production systems.

The Future

With a more evolved release cycle, users now have the ability to view a detailed report of what is going into the next release via our GitHub Milestones. These milestones are planned by our engineering team at the beginning of every month and go through a checkup in the middle of the month.

Have an idea for a feature that can fit into this release cycle? Open an issue on GitHub.

See you at 8.7!

Your code is broken. Let's Fix it.
Get Started

More from the Sentry blog

ChangelogCodecovDashboardsDiscoverDogfooding ChroniclesEcosystemError MonitoringEventsGuest PostsMobileMoonlightingOpen SourcePerformance MonitoringRelease HealthSDK UpdatesSentry
© 2024 • Sentry is a registered Trademark
of Functional Software, Inc.