Since this comes up a lot, I want to put all of the information in one place so there’s an easy way to reference people.
tl;dr: sometime in the next few months, when we stabilize our cutover points for new infrastructure
We haven’t tagged a new version of Sentry since 9.0, which is nearly two years ago. Why?
We used to tag versions every month. @matt would sit down and spend a day (or three) going through and making sure the changelog actually represented things, building a bunch of packages, running a bunch of scripts, eventually pushing a new tag to PyPi. This worked somewhat well when the team was 10 folks, as we’d try to get every engineer to write a reasonable changelog entry as part of their PR.
Eventually, @matt and others got busy with, frankly, more important things. Things that let us actually build Sentry and keep it free and open source (e.g. features or other concerns of our paying customers). Additionally we’re far larger than a 10 person team these days. Sentry is now 75 people in two countries and four timezones. The things that allowed us to efficiently keep tagging arbitrary versions of Sentry didn’t scale for long.
We kept saying we’d try to figure out a way to generate a changelog (e.g. automate it), or automate at least tagging of versions, but we never did. The same reason we didn’t do that is the same reason we stopped tagging versions manually: we had other, more important things to do.
Now fast forward to today, and what we’re intending to do:
- We’re building a (paid) Single Tenant offering. This will force us to have version points and lag time between upgrades.
- We’re hiring a full time Open Source Engineer. They will own the release cycle of Sentry, address concerns brought up by the community, and generally ensure the GitHub issue tracker doesn’t become a shit show.
- We’re planning a cutover release (Sentry 9.1, or 10, who knows) which will be the last upgrade before a new versioning scheme.
- We’re in the (very early) planning stages of what the new versioning schemes will look like, and how Single Tenant vs Open Source will work.
- We almost certainly wont maintain a changelog of features and fixes. We’ll certainly document large infrastructure changes, and upgrade concerns, but we make dozens of changes every week now, and a changelog simply isn’t a good spend of time.
Once we’ve tagged the next version, we’ll be making significant changes to how we release Sentry, as well as a huge set of breaking infrastructure requirements.
I’ve spoken about some of this before, but fundamentally Sentry will stop supporting a lot of custom installation code. Things like MySQL will be completely removed, Snuba (our new Clickhouse-based event storage) will become required, and a lot of the hard-to-maintain freedom will go away. This is also likely when we’ll start making the push towards Django 1.8+ and eventually Python 3.
When will the next version be tagged? We don’t know exactly. We’re trying to finalize some things in Q1, and I’d like to get it done in the same timeframe. That said, we have to get the customer facing changes done before we can take on the secondary (“nice to have”) items. Given that we actually haven’t tagged Sentry in a long time, we’re also mandating a larger QA process to ensure there’s no obvious mishaps (like a broken setup wizard when migrating from 9.0).
I’m happy to answer more questions, but it’s important to remember that Sentry (Open Source) is literally Sentry (the company), and we’re not intentionally crippling the open source product, we just frankly don’t think people should be limiting their ability to use Sentry by requiring arbitrary, blessed-but-not-really, check-in points.
. I’m running 