The goal of this 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 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)
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 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 :
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 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 depends on the last major X.0 version of the SonarQube API
- For each SonarQube plugin there must at least one release on each major 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 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:
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:
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 SonarQube3.6.