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!