Version 5.0.1 Upgrade Path Inquiry

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:

5.6?.X? LTS > 6.7?.5? LTS > 7.9.6 LTS > 8.9.10 LTS > 9.9.4 LTS

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:

  1. 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
  2. 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?
  3. What is the last LTS for version 5 and what is the last LTS for version 6
  4. Are the downloads available for the earlier LTS versions?
  5. 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?
  6. 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?
1 Like

Hey there.

Welcome to the future :star_struck:

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.

However:

Yes.

5.0.1 → 5.6.7 → 6.7.7 → 7.9.6 → 8.9.10 → 9.9.4

You can find them buried in here.

It’s not accessible. I even tried poking around https://web.archive.org/ and came up short.

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?

4 Likes

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.

Hey there.

Java, XML, and Javascript are indeed all supported out of the box.

Be aware that GitHub - racodond/sonar-json-plugin: SonarQube JSON Analyzer and GitHub - racodond/sonar-jproperties-plugin: SonarQube Java Properties Analyzer are community-supported plugins that are no longer maintained and not compatible with the most recent SonarQube versions.

If I recall, these analyzers usually provide quite limited value, and in a commercial license, eat up your Lines of Code.

It depends where those rules are coming from – rule templates (did those even exist in 5.0.1)? Then theoretically, yes.

Custom plugin development? (Those plugins will need to be updated to use the latest APIs)

1 Like

Hey Colin,

Yes the custom rules are from rule templates. Does this mean these rules could be migrated?

They would theoretically survive a migration. And, I would still suggest recreating them in a new instance.

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.

You can use GitHub - jborgers/sonar-pmd: ☕️ PMD Plugin for SonarQube (the latest version is compatible with SonarQube v9.9).

Alternatively you can import PMD reports as external analyzer reports

There was recently a discussion on choosing between plugin vs. importing reports here:

I’m guessing you’re concerned with XML here. You’ll be looking for xml:XPathCheck