SonarQube community edition upgrade

SonarQube
1

Hi,
We are planning to upgrade our SonarQube community edition from sonarqube-7.9.4 to sonarqube-9.5.0.
Can someone tell me what would be the upgrade path. Can we directly go from 7.9.4 to 9.5.0 ?

Thank you,
Ravi

2

Hi,

Welcome to the community!

Your upgrade path is:

7.9.4 → 8.9.8 → 9.5 (last step optional)

You may find the Upgrade Guide and the LTS-to-LTS Upgrade Notes helpful. If you have questions about upgrading, feel free to open a new thread for that here.

 
HTH,
Ann

3

Thank you Ann.

So I have a ZIP package - sonarqube-8.9.8.54436. So I will upgrade to this version and see if require I will go to 9.5.

Appreciate your assistance on this.

Thank you,
Ravi.

1 Like
4

Ann,

One last question,
I see there is sonarqube-8.9.9.56886 from below download page and is showing as LTS.

Do you suggest to go with 8.9.9 LTS or 8.9.8 (sonarqube-8.9.8.54436) from my current version 7.9.4 ?

Thank you,
Ravi

5

That raises a good question: is any x.9 version considered LTS, or only the very last sub-version? Meaning, for instance, if one is currently at sonarqube-8.9.8.54436 and wants to upgrade, say, to 9.5, is it first required to upgrade to 8.9.9.56886 or can an upgrade to 9.x be made from any 8.9?

6

Hi all,

Thanks for asking @RT_Reddy_P! I see I need to update my boilerplate. :flushed:

Technically, only the latest point release is considered “the LTS”, and is always the preferred version.

That said, I’m not going to hassle you with “upgrade” boilerplate when you have a question about an earlier point version. But you may be asked to upgrade to see if doing so solves the problem.

To flesh this out just a little more, a point-to-point upgrade should be effortless, particularly if you’ve configured the Elasticsearch storage path. The downtime in an upgrade is waiting for the database migrations and the ES indices rebuild. A point-to-point upgrade (of any version, really) won’t include any DB migrations (unless we’ve really muffed it!) and there’s no need for the ES indices to rebuild if you’re storing them externally to $SONARQUBE-HOME.

And since we only put out point releases to fix serious bugs or patch vulnerabilities, there’s really no reason not to be on the latest point release.

 
HTH,
Ann

7

Hi @MisterPi

I got ahead of myself & I see now I didn’t fully address your question.

The reason there are waypoints in the upgrade path is that its costly maintenance-wise to keep all the upgrades from all the versions in the code. So 8.9(.*) knows how to upgrade the DB schema from 7.9(.0) through 8.8. But it doesn’t have the upgrades from 6.7.

Since there are no DB upgrades in a point version, that means that for the purposes of an upgrade path, every point release of a version is equivalent. So you could use 8.9(.0) in your upgrade path on the way to 9.5 and it would be just as good as using 8.9.9. (But why bother digging up the old point release?)

 
HTH,
Ann

1 Like
8

Thanks. By “point version” you mean the second number? So when you say “no DB upgrades in a point version” you mean that x.y.z → x.y.(z+n) (n>0) should be trivial, whereas x.y → x.(y+n) may be more involved because it may require a DB migration? (Edited in light of ganncamp’s clarifications.)

It seems that in Ravi’s case, using the zip they already downloaded should be fine, since it’s just a stepping stone to the 9’s. Whereas if they were going to stop at 8.9 then of course it would make sense to get the newer 8.9.9.

(Ravi: be aware that there were major API changes from 7 to 8. In particular, the “security hotspot” type was given an entirely new API, with many of its capabilities significantly curtailed, such as filtering, particularly for the web_api. If you have scripts that call the web_api, they’ll need some mods.)

1 Like
9

Hi,

Yes, mostly. There are some x.(y+n) upgrades without DB migrations.

Yup.

 
Ann

1 Like