Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents


Versioning Strategy

The goal of this versionnig versionig strategy is both to :

  • Release often release early in order to get quick feedback from the SonarQube community
  • Release some stable versions of the SonarQubeplatforms SonarQube platforms for companies whose main priority is to set-up some very stable environments. Even if the price for such stable environnements is to not benefit of latest and sexy SonarQube features
  • Support the the API deprecation strategy (see next section)


  • Each two months a new version of SonarQube is released. This version should increment the minor digit of the previous version (ex: 4.2 -> 4.3)
  • After three (or more) releases, a bug fix release is done and the to become the new LTS. Then the major digit of the previous version is incremented to start a new cycle (ex: 4.3 -> 5.0)

And here is the strategy in action :

Code Block
4.2 -> 4.3 -> 5.0 -> 5.1 -> 5.2 -> 5.3 -> 6.10 -> ...                  <- New release each 2 months 
        |                    |       |
5.0      4.3.1 -> 4.3.2 -> ...        6.0  5.3.1 -> 5.3.2 -> ...               <- MajorLTS releases containing only bug fixes each 6 months 


API Deprecation Strategy

The goal of this deprecation strategy is to make sure that any deprecated API will be dropped without any side-effects at a given planned date. The expected consequence of such strategy is to ease the evolution of the Sonar API by making such refactoring painless.


  • Any API must be deprecated before being dropped
  • A deprecated API must be fully supported until its drop (For instance the implementation of a deprecated method can't be replaced by a "throw new UnsupportedOperationException()")
  • If an API is deprecated in version X.Y, this API will be dropped in version (X+12).30. Example: an API deprecated in 4.1 is supported in 4.2, 4.3, 5.0, 5.1, 5.2, 5.3 and is dropped in version 56.30.
  • According to the versionning strategyversioning strategy, that means that an API can remain deprecated before being dropped during 6 to 12 months.
  • Any release of a SonarQubeplugin SonarQube plugin must at least depends on the last major X.0 latest LTS version of the SonarQube API
  • For each SonarQubelugin SonarQube plugin there must at least one release on each major LTS version of SonarQube, which means at least one release each 6 months.
  • No usage of deprecated API is accepted when releasing a plugin. It raises a critical issue in SonarQube analysis. This issue can't be postponed.
  • No depreacted deprecated API introduced 2 major versions ago is accepted when releasing SonarQube. It raises a critical issue in SonarQubeanalysisSonarQube analysis. This issue can't be postponed.
  • An API is marked as deprecated with both:
    • the annotation @Deprecated
    • the javadoc tag @deprecated whose message must start with "in x.y", for example:

      Code Block
       * @deprecated in 4.2. Replaced by {@link #newMethod()}.
      public void foo() {


And here is the Deprecation Strategy in action where A is the name of a method:

Code Block
  A deprecated                        A removed
       |                                  |
4.1-> 4.2 -> 4.3 -> 5.10 -> 5.21 -> 5.32 -> 6.10       
              |                    |

Deprecated Libraries

Removal of libraries do not follow the same strategy than standard APIs. They usually require much more time than 2 series of versions to be fully dropped.


  • prototypejs and scriptaculous, replaced by JQuery
  • commons-configuration, replaced by org.sonar.api.config.Settings
  • XML parsers. Prefer JSON when possible.
  • Hibernate, replaced by MyBatis
  • GWT and JRuby on Rails, replaced by JRuby on Railspure JS UI

Moreover note that Java 5 is no longer supported since SonarQube3SonarQube 3.6.