Inside Sentry is a series in which we talk about how we build Sentry, including the technology we use and the workflows that move us forward.
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 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 getsentry.com 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.
Sentry is loosely versioned around semver, but in practice,
this is much harder to adhere to compared to libraries. But what this means for
- 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
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
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. Additonally, 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.
application to drive our UI. For those that have dabbled into Python packaging
ship a package including both. At the end of the day, we want our users to be
burdened as little as possible with installation.
We have two different distributions, a Docker image on
Docker Hub, and
PyPI (the standard Python package
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
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.
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
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
See you at 8.7!