Walking the Tightrope: Balancing Agility and Stability
About a year ago we declared a Long Term Support (LTS) version for the first time ever, and recently, we declared another one (version 4.5.1). But we never talked about what LTS means or why we did it.
Here's the story:
SonarSource is an agile company. We believe deeply in the agile principles, including this one:
Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
So that's why we deliver a new version about every two months. We know we need to get our changes out to the users so they can tell us what we've done well, and what we haven't. (Feedback of the latter kind is more frequent, but both kinds are appreciated!) That way we can fix our goofs before they're too deeply embedded under other layers of logic to fix easily.
That's the agility part: release frequently and respond to customer feedback. But what about stability?
We know that many of our users are in large organizations. Since many of us came to SonarSource from large companies, we understand how well such organizations deal with frequent change: not well at all, sometimes. Instead, they need stability and reliability.
For a while, that left us with a conundrum: how could we be responsive to the customer need for stability, and still be agile?
(Drum roll, please!) Enter the LTS version.
An LTS version marks a significant milestone for us: it means that through incremental, we've brought a feature set to completion, and worked out the kinks. The vision that was established (a year ago, in this case) has been achieved, and it's time to set out a new vision. (More on that soon!)
Once a version is marked LTS, we pledge to maintain it and fix any non-trivial bugs until the next LTS version is released. That way, users who need stability know that they'll never be forced to upgrade to a non-LTS version just for a bug fix.
And if a bug fix is required for an LTS version, you know you can upgrade to it without any other change in behavior or features. I.e. it's completely transparent to your users. Of course, we don't mark a version LTS until we know it's stable, and we've fixed all the bugs in it that we're aware of. So the chance that you'll need to perform this kind of transparent upgrade are small.
Of course, there are trade-offs. We release frequently, and pack a lot work into each release. By opting to stay with an LTS version, you trade benefiting from the cool new features for stability (yes, I know that's a trade worth making for many people).
But there's another trade-off to be aware of. When you go from one LTS version to the next, you'll see a lot of change all at once. This time the jump from one LTS to the next includes significant UI changes, plugin compatibility differences, and changes that impact project analysis (possibly requiring analysis job reconfigurations). There's an overview in the docs.
On the whole, a jump from one LTS to the next one will be awesome, but you need to be aware that it may not feel as trivial as SonarQube upgrades usually do. Really, it's just a question of how you want to rip off the Band-Aid(R).