Versionning Strategy

The goal of this versionnig strategy is both to :

• Release often release early in order to get quick feedback from Sonar community
• Release some stable versions of the Sonar 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 Sonar features
• Support the the API deprecation strategy (see next section)

The rules are :

• Each two months a new version of Sonar is released. This version should increment the minor digit of the previous version (ex: 4.2 -> 4.3)
• After three releases, a bug fix release is done and the major digit of the previous version is incremented (ex: 4.3 -> 5.0)

And here is the strategy in action :

    
4.2 -> 4.3 -> 5.1 -> 5.2 -> 5.3 -> 6.1        <- New release each 2 months 
        |                    |
       5.0                  6.0               <- Major 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.

The rules are:

• 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+1).3. Example: an API deprecated in 4.1 is supported in 4.2, 4.3, 5.0, 5.1, 5.2 and is dropped in version 5.3.
• According to the versionning strategy, that means that an API can remain deprecated before being dropped during 6 to 12 months.
• Any release of a Sonar plugin must at least depends on the last major X.0 version of the Sonar API
• For each Sonar plugin there must at least one release on each major version of Sonar. 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 Sonar analysis. This issue can't be postponed.
• No depreacted API introduced 2 major versions ago is accepted when releasing Sonar, It raises a critical issue in Sonar 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.1 -> 5.2 -> 5.3 -> 6.1       
              |                    |
             5.0                  6.0          

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.

Current deprecated libraries are :

• 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, replaced by JRuby on Rails

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