Extend

SonarQube

Scanners

Plugins

Extension Guide

Skip to end of metadata
Go to start of metadata

Versioning Strategy

The goal of this versioning strategy is both to :

  • Release often, release early in order to get quick feedback from the SonarQube community
  • Release stable versions of the SonarQube platform for companies whose main priority is to set up a very stable environment. Even if the price for such stable environments is missing out on the latest, sexy SonarQube features
  • Support the API deprecation strategy (see next section)

The rules are :

  • 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 version is released, and becomes the new LTS. The major digit of the subsequent version is incremented to start a new cycle (ex: 5.6 -> 6.0)

And here is the strategy in action :

    
4.4 -> 4.5 -> 5.0 -> 5.1 -> 5.2 -> ... -> 5.5 -> 6.0 -> ...     <- New release every ~2 months 
        |                                  |
      4.5.1 -> 4.5.2 -> ...              5.5.1 -> 5.5.2 -> ...  <- New LTS

 

API Deprecation Strategy

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

The rules are:

  • An 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+2).0. 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 6.0.
  • According to the versioning strategy, that means that an API can remain deprecated before being dropped during 6 to 12 months.
  • Any release of a SonarQube plugin must at least depend on the latest LTS version of the SonarQube API
  • For each SonarQube plugin there must at least one release on each LTS version of SonarQube, which means at least one release each 6 months.
  • No use of deprecated APIs is accepted when releasing a plugin. It raises a critical issue in SonarQube analysis. This issue can't be postponed.
  • No deprecated API introduced 2 major versions ago is accepted when releasing SonarQube. It raises a critical issue in SonarQube 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:

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

The following example shows the amount of APIs marked as deprecated during the releases 4.x:

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

  A deprecated                        A removed
       |                                  |
4.1-> 4.2 -> 4.3 -> 5.0 -> 5.1 -> 5.2 -> 6.0       
              |                    |
            4.3.1                5.2.1          
  • No labels