Ace Your SonarQube Version Upgrade!

SonarQube users looking to upgrade to the latest Long-Term Support (LTS) version have significant reasons to do so. During a recent webinar hosted by SonarSource, product and community management teams outlined the essential steps and considerations for ensuring a smooth upgrade experience. The session emphasized that upgrading is not optional for organizations committed to long-term clean code strategies—it is an inevitable necessity that should be carefully planned and executed.

Understanding SonarQube Release Cycles

SonarQube operates on two distinct release cycles: LTS (Long-Term Support) versions and latest non-LTS versions. A new LTS version is released approximately every 18 months, while non-LTS releases arrive every two months. The current LTS version is SonarQube 9.9, while the latest release is version 10.0. LTS versions are designed for users prioritizing stability and refined features who can only accommodate upgrades every 18 months due to downtime and resource constraints. In contrast, non-LTS releases cater to organizations needing bleeding-edge features, including support for new programming language versions, and that can handle upgrades every two months. New features are typically introduced through non-LTS major versions (such as 9.0, 9.1, and 9.2) before being significantly hardened for LTS releases, which must remain supported for 18 months post-launch.

Upgrade Paths and Strategic Planning

The upgrade path depends entirely on the user's current SonarQube version. Users running LTS to LTS versions have the simplest upgrade path—simply moving to the next LTS release. For example, users on version 8.9 LTS should upgrade directly to 9.9 LTS. Those running older non-LTS versions, such as 8.3, must first upgrade to the corresponding LTS version (8.9 LTS) before advancing to 9.9 LTS. Users currently on non-LTS versions within a major release should target the newest version of that release cycle. Importantly, users running the latest version 10.0 who prefer stability will need to wait until the end of next year for a 10.x LTS release before committing to a long-term support path.

What to Expect During an Upgrade

Upgrading SonarQube involves multiple dimensions of change. Users should anticipate alterations to both server-side requirements (where the SonarQube instance is hosted) and scanner-side requirements (where analyses are executed). Application-level changes include new features, performance improvements, bug fixes, security enhancements, and API deprecations or removals. One of the most significant user-facing changes involves updated rules and quality profiles. Quality profiles represent the set of rules applied to analyzed languages, and new SonarQube versions frequently introduce additional rules to built-in profiles like the default Sonar Way profile.

Mitigating New Issues Through Issue Backdating

To prevent quality degradation perceptions, SonarQube implements issue backdating—a process ensuring that new issues raised by newly introduced rules do not pollute the new code period. Instead, issues discovered through new rules are automatically backdated to the date when the affected line was last modified by a developer. This approach maintains code quality metrics integrity and ensures that new issues appear only in the appropriate code history context rather than inflating new code concerns. The webinar also covered testing, troubleshooting strategies, and provided a live demonstration of the upgrade process, though the transcript does not provide those specific details.

Key Takeaways

• SonarQube upgrades are inevitable for organizations using the platform long-term; users must eventually migrate to an LTS version regardless of their current release cycle choice
• LTS versions release every 18 months for stability-focused users, while non-LTS versions release every two months for feature-hungry organizations
• Upgrade paths vary significantly based on current version; users should identify their starting point to determine the correct sequential upgrade targets
• New rules introduced in upgraded versions use issue backdating to avoid polluting new code metrics, ensuring fair quality assessments
• Both server and scanner requirements may change during upgrades, requiring comprehensive testing before production deployment