we are currently running the Enterprise version of SonarQube Enterprise (8.9.2 (build 46101)) and now want to support JDK 17 projects once the LTS of JDK 17 arrives.
If I understand Will Java 16 and 17 be supported in SonarQube 8.9 LTS? this would only be possible by using the non-LTS version of SonarQube (9.x). First for me it is a pity if the LTS of SQ does not support all LTS versions of Java.
That said: if I remember correctly if we switched to use SQ 9 Non-LTS instead of SQ 8 LTS we might experience other problems as SonarSource does not strive to be back-wards compatible concerning data in non-LTS, so we might end up with being forced to throw away our old analysis.
Could someone state what are possible disadvantages of using the non-LTS version? If we follow and update all minor versions of the non-LTS will we be able to keep our data?
You are correct in your understanding: you must upgrade to the SonarQube 9.X releases in order to obtain support for JDK 17.
The only real disadvantage to upgrading to non-LTS is that you will have to upgrade about every 2 or 3 months and that breaking changes/regression may occur, which can be quickly verified and addressed by posting here in SonarSource Community or obtaining Commercial Support. Here’s a summary of our LTS definition: SonarQube Long Term Support version | SonarQube
The big advantage to upgrading to the latest/non-LTS version:
you always get the latest analysis SAST (CWE & OWASP) rules and language analyzers
you get bug fixes quicker (LTS only receives critical bug fixes)
you will get new features and integrations much quicker
reduced cognitive overload by the time you land on SonarQube 9.x LTS
JDK 16 and JDK 17 support
If JDK 17 is that important, then sticking to the latest version of SonarQube is best so you get support for it quicker.
Hi Joe,
thanks for the quick answer.
Updating every 2 or months is hopefully not a big thing, as well update e.g. plugins weekly.
“breaking changes may occur” is exactly why we use the LTS. We keep some history (1 year of about 1200 projects) and we do not like to loose that.
Could you maybe link some breaking issues which happened in the past so we may assess the risk?
Oops I forgot to address that point, thanks for asking it again.
No, there is unlikely to be any loss of history. If you want to protect yourself, verify your Housekeeping settings, do weekly backups of your DB, backup your DB before upgrades, perform DB maintenance such as reindexing and calculating statistics as needed, and practice the upgrades in a test/lower environment. Rehearsing the upgrade and reviewing the upgrade notes that we list for each minor version upgrade is essential so that you can ensure the upgrade will occur smoothly and nothing is a surprise.
In the past, some of the biggest changes affecting Analysis occurred as described in LTS to LTS Release Upgrade Notes | SonarQube Docs, none of which would constitute “breaking changes” except the Jacoco coverage XML file requirement:
JavaScript security analysis can take longer (8.8)
Not a breaking change but a quality improvement with a performance cost.
JavaScript, TypeScript, and CSS analysis now requires Node.js 10+ (8.7, 8.8)
Big deal for users who relied on very old versions of Node.js.
Security Hotspots in the built-in Quality Gate (8.3)
If you didn’t pay attention to the release notes, you would have been surprised about this change.
Updated .NET code coverage (8.3)
This affected .NET users whose coverage values dropped and could have affected their Quality Gate.
Support for .exec format JaCoCo Coverage Reports dropped (8.2)
This one was a big issue for several users who did not heed our warnings in the log. We stopped accepting .exec binary format and required .XML format. See here for more info.
Short-lived and Long-lived branches are now just branches (8.1, 8.4)
This was a big issue for customers who did not optimize their Housekeeping settings and never cleaned up their excessive number of short-lived branches, which got converted into a regular branch and thus duplicating a lot of data and bloating their DB unnecessarily. Not a breaking change but highly impactful if you don’t keep up with maintenance independent of LTS or latest version.
In summary, there wasn’t any true breaking changes that would have caused loss of history. In my opinion, backing up your DB frequently is essential.
The link to “3 steps to a smooth upgrade guide” is missing?
We keep 14 daily incremental PostgreSQL DB backups and two weekly full backups, so in regards to this we should be on the safe side.
That one said: is nuking the ElasticSearch directory and rebuilding the index inbetween needed/recommended? SonarQube takes some time to rebuild it from PostgreSQL
The only downside to nuking/reindexing Elasticsearch directory is the slow reindex time that can occur once you have a lot of projects and portfolios and analyses to reindex. Since SonarQube 8.4, we allow access to your projects as they become available:
Project, Application, and Portfolio availability when rebuilding Elasticsearch indexes (8.4)
From now on if your upgrade requires the rebuild of Elasticsearch indexes, your projects and Applications will become available as they are reindexed. Portfolios won’t be available until all projects are reindexed. (MMF-2010)
I recommend not reindexing so often and only occasionally as you see fit (e.g. weird UI issues or if you notice errors in the Elasticsearch es.log file)…
