Determining the server upgrade path

This section explains SonarQube release cycle model and the principles to follow in order to determine if you can perform the upgrade directly or must upgrade first to intermediary version(s).

SonarQube release cycle model

SonarQube follows semantic versioning. A new major or minor version is released every 2 months, and a new Long Term Support (LTS) release is declared approximately every 18 months. Only the latest major release receives active support (updates and patches). During that time, the previous major release receives LTS support (security patches and fixes of blocker bugs) until the next LTS is declared. 

SonarQube version follows the MAJOR.MINOR.PATCH model as shown below.

Major version number

The major version number represents a series of releases with high-level objectives for the release cycle. It's incremented with the release following an LTS version (for example, the release following 7.9 LTS was 8.0).

Minor version number

The minor version number corresponds to incremental functional changes within a major release cycle. At the time of an LTS release, the release cycle is closed and the minor version number is frozen.

Patch release number

The patch release number represent patches that fix blocker or critical problems. 

Upgrade path determination principles

To determine your upgrade path, consider the following principles:

• You can upgrade directly from a non-LTS version to another if there is no LTS version in your upgrade path.
• If there is at least one LTS version in your upgrade path, you must first upgrade to each intermediate LTS and then to your target version.
• When upgrading to an LTS version, you should directly upgrade to its latest patch. 
• You can upgrade from the latest LTS version to the latest non-LTS version directly. 
• If you're migrating from an earlier patch version of an LTS, you can upgrade directly to the next LTS. You don't need to install any intermediate patch versions.

Upgrade path examples