From what I understand, in the current SonarQube Community Build model there is a December release every year (e.g., today 24.12, and at the end of the year 25.12) that serves as a mandatory “bridge” to update between years.
Can these December releases be considered equivalent to an LTS/LTA in the Community Build — meaning stable versions that can be kept for a longer period before updating again?
Today I’m on version 9.9.3 LTS and I know I first need to go to 24.12 before moving to 25.x. Can I update now to 24.12, run this version in production for a few months, and then jump from 24.12 directly to 25.12 when it becomes available?
The idea is to reduce update frequency, since Community Build has monthly releases.
My intention in following this flow (9.9.3 → 24.12 → 25.12) would be:
-
Expected pros:
-
Reduce the number of upgrades by avoiding applying every monthly release.
-
Have more time to validate plugin and integration compatibility.
-
Minimize frequent changes for teams using SonarQube.
-
-
Possible doubts/cons I want to confirm:
-
Whether staying on 24.12 for many months could introduce security risks, since only the most recent versions receive patches.
-
Whether plugins and integrations might break when jumping directly from 24.12 to 25.12.
-
Whether SonarSource has any official recommendation on the maximum time to remain on a “bridge” version.
-
I’d like to understand if this approach is supported and safe under the Community Build model, and whether other teams have adopted this yearly update cycle using only the December versions as main milestones.