Development Tools: Long-Term Support ("LTS") or the very latest?

The SonarQube v9.9 LTS comes out today! :partying_face:

A SonarQube LTS release represents the cumulative delivery of a major series of SonarQube. A new SonarQube LTS is released about once every 18 months, and focuses on long-term operational stability, particularly for organizations where regular upgrades are hard to orchestrate. You can read more about “What is an LTS?” on our website.

SonarQube also offers a non-LTS or Latest release cycle, with new features, rules, and increased support for newer language versions being released every 2 months. There is a new non-LTS release about every 2 months.

There are good reasons to use either: big enterprises (with giant SonarQube instances) tend to prefer running an LTS version, while smaller teams can handle upgrading every time there’s a new release. Lots of development tools operate with a similar model, like Jenkins and Jira. In recent years, there has also been a move towards SaaS offerings where you are always using the latest version (SonarCloud works like this).

We want to know: What do you prefer using, in your personal or professional software development? LTS releases or the very latest? Does it vary depending on the tool?

LTS 100% due to policy, and it’s very annoying when key bugfixes aren’t backported to LTS versions (kind of makes you wonder what that LTS is supposed to mean!).

2 Likes

Thanks for sharing, @unblocker! I guess that means you’ll be prioritizing the upgrade to SonarQube 9.9? :smiley:

Is that something that can move quickly in your organization (days or weeks?) or will it take longer?

 
Ann

We’ll find out, but the lack of actually backporting key bugfixes in “LTS” versions of Sonar specifically means much less perceived value in doing that update, and the fact that this version only came out yesterday probably means an increase in perceived risk of trying to move quickly.

3 Likes

Always latest.

In my opinion the concept of LTS is outdated. The programming language world is changing fast, so Sonarqube has to and developers too.

Companies which rely on LTS versions I guess are mostly using outdated versions of the programming language, so they should rethink their whole development process.

Kind regards,
Michael

2 Likes

I would like to stick with a LTS - but with updated scanners. I know, you removed the possibility to upgrade the scanner plugins some years ago. But as the C# scanners of 9.9 LTS for example doesn’t recognize the current .NET 6 LTS (see C# S3900 ArgumentNullException.ThrowIfNull) we need to upgrade more often than every 18 months. C# was released Nov. 2022, maybe SonarQube 10 in autumn 2024 will have then scanners which does fix this issue. Too late IMHO.

2 Likes

We started in the past with using LTS to avoid bigger operative issues. We now streamlined our process of building our own Docker image with the plugins we need and update these on a weekly base automatically.
The rollout to the QA stage is completely automated and we have some small acceptance tests.
Because we direly needed to support JDK 17 before 9.9 came out, we switched last year to latest. Which was less of a problem then we thought.

1 Like

Just wanted to chip in that we also use LTS versions of just about everything, but have had problems with the schedule of Sonar specifically.

18 months is far too long for an LTS cycle, especially when it takes many months for Sonar to update scanners to add support for language/runtime updates. In month 17 of that cycle, you can easily find yourself stuck on a 3+ year old version of a language, which is an eternity on the modern web. Sonar is supposed to increase our overall code quality, but it’s a net negative if it means that we can’t update dependencies because they’ve moved on to a newer version of the language while we’re stuck on the old one Sonar supports.

1 Like

@mfriedenhagen now that you’re off the LTS, do you plan to keep adopting the latest versions as they come out?

@milbrandt we’ve talked before about a shorter LTS cycle. I think we’re caught between the very large organizations that find upgrading painful and don’t want to do it more often and the smaller orgs that just want the features. You said you “would like to” stick with an LTS. Does that mean you don’t? And I’m curious: do you prefer LTSs for fear of the “bleeding edge” or something else?

There is always going to be a tension between having the latest greatest and having stability for a period of time.

I do find the Sonar support model somewhat agressive - it is “all or nothing” - basically you stick to the LTS version and miss out on bug fixes/new features you need or you upgrade to a version that includes them and you are now on the cycle where every new release immediately means the previous version is technically no longer supported - so you theoretically have to keep upgrading in order to be supported.

Even sticking with the LTS version, as soon as the new one comes out, you techincally don’t support the old one anymore so LTS users have a potentially bigger hurdle to do an “immediate” upgrade than those who have been updating every two months…

It is not always possible (or desirable) in an organisation, even a small-ish one to immediately jump to the just release version of something. Other work priorities, or simply a desire to wait a few days/weeks to see if any major bugs pop up can mean that you can’t “immediately” upgrade to the newest version.

If you look at the Microsoft support model for .NET, they have a release every year - “odd” versions are supported for about 6 months after the next “even” LTS release, and LTS releases themselves are supported for I believe 3 years - in both cases you have a fairly significant overlap of official support in order to be able to plan your upgrades, test them, execute on same.

I’m not suggesting that Sonar continue support for these sorts of extended timeframes but it would not seem unreasonable for example to have an LTS release every year that is supported for say 6 months after the next LTS release and non-LTS releases every 2 months which are supported for 3 months after the next release (LTS or otherwise)

As others have wondered in this thread, if bugfixes are not back-ported to the “LTS” version then what actual purpose does an LTS version serve, other than to be a line in the sand? Particularly when a new release requires an immediate upgrade in order for support to continue.

I accept that you may continue “unofficially” to support older versions but it doesn’t seem particularly satisfactory to be in that position.

At the other end of the scale of trying to keep up with the latest greatest in general, I know some vendors who release new versions of their apps/packages every other day it seems, so keeping up with latest of even one of them would essentially be a full time job - in such cases, we have to take a view on upgrading at some regular cadence to keep “reasonably” up to date.

3 Likes

Hi @ganncamp
I would like to stick with LTS as

  1. there is always a downtime of some hours (backup, upgrade, migrate database, install as service),
  2. to keep on a supported version (we are paying for the DE),
  3. and the risk that something is broken - we had this in the past some time. Once I even got an unreleased C++ scanner for testing.

In reality, we upgrade from time to time in-between, when I spot an important improvement in the release notes of the intermediate releases AND it is not critcal to have a downtime on Friday :wink: Thus, I was upgrading from 9.4 to 9.9 LTS two weeks ago.

2 Likes

Hi @tbutler,

Thanks for taking the time to elaborate.

I’d like to clarify that point: The LTS is meant for stability. This is the reason why no new features/improvements are backported to the LTS. Still, the LTS fixes blocker bugs and vulnerabilities in SonarQube itself and in the underlying analysis so that you can get the most important fixes without being impacted by any changes to functionality. Hope it helps.

Chris

Thanks for the clarification @Chris - that makes sense.

Hi @ganncamp,

we will probably stay with latest because our plan is to quickly support JDK 21 once it comes out in September of this and that one will probably not supported by the LTS anyways.
With our current process the overhead of updating the core is not much bigger than updating the plugins, which we do every week anyways.

Best Regards
Mirko

1 Like