Current installed version - v5.0.1
Target version - LTS v9.9
Regarding Upgrade Paths and Procedures
Based on extracts from SonarQube Docs (Determining the server upgrade path | docs.sonarsource.com), we believe the upgrade path to most likely follow this trend:
As there aren’t any documentation from the official site for the earlier versions (especially 5 & 6) here are some queries I’m hoping can get clarified:
Does this statement - upgrading to each intermediate LTS and then to your target version - from the SonarQube Docs, apply for much older versions like 5 & 6
Alternatively given our current installation is on version 5.0.1, could you provide a detailed list of the required intermittent versions we need to upgrade through to reach LTS version 9.9?
What is the last LTS for version 5 and what is the last LTS for version 6
Are the downloads available for the earlier LTS versions?
Is the old documentation for v5 & v6 archived and accessible for us to help us with the intermediate upgrades if that is the chosen path, or/and even just to understand any key differences to enable a migration?
Are there benefits and drawbacks from performing a fresh installation of SonarQube LTS version 9.9 against upgrading from our current version?
Impact on Rules and False Positives
Preservation of Custom Rules and False Positives: How does the upgrade process affect existing custom rules and marked false positives? Are there steps we should take to ensure they are preserved and correctly migrated to the new version?
Compatibility of Rules: Are there any known compatibility issues with rules and code quality profiles between version 5.0.1 and version 9.9? How can we address any such issues?
SonarQube v5.0.1 was released in 2015 (almost a decade ago!). The difference between a v5.0.1 and v9.9.4 instance are going to be absolutely seismic. Any continuity of data will be limited. Quite frankly so few users have made this migration that I’m not even sure you’d be successful. There is exactly 1 developer still working on the SonarQube platform today who was working on it when 5.0.1 was released.
Benefits: You’ll maintain a shred of your sanity. Benefits: You get a clean slate, with a decade of Sonar’s development into the field of static code analysis and, more broadly, Clean Code. You’ll set yourself up for success using Sonar into the future, instead of holding onto old results. I suspect your platform will be much more stable, and coherent, starting from scratch. Drawbacks: You’ll lose any existing issue dispositions (issues marked as false-positive / won’t fix) and any other configuration. However, I can’t even say with confidence that those existing issues will still be raised by the v9.9 SonarQube instance you end up on.
My advice would be to restart your SonarQube journey from scratch. We would reccomend to any customer (or user) starting from 5.0.1 today, to start from scratch.
Just curious (we’re all curious) – how many projects are on your 5.0.1 server? What languages are you analyzing?
Thanks Colin for your detailed response. You’ve been of great help. To answer your question and tackle your curiosity, I’d say I couldn’t definitively tell you how many projects make use of the current version as there are quite a few, however I can tell you that we analyse Java, XML, JSON, Java Properties and JavaScript languages within our Quality profiles. I’m expecting these would be covered in the latest LTS.
Could you also confirm for certain that all existing Custom rules would not be migrated to each of the intermittent upgrade versions on the way to the target LTS version.
Thanks.
Hi Collin… Thanks for the responses and I agree, recreating the rules would be best.
With regards to LTS9.9, could I ask if there are alternatives to the PMD plugin or what your latest version of Sonar PMD Plugin is.
Also which template can be used to define new XPath-based rules please.
