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.
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
mastergit 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.
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 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!