Full documentation for SonarQube has moved to a new location: http://docs.sonarqube.org/display/SONAR

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

The goal of this deprecation API 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 it 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 major version X, this API will be dropped in major version X + 2. Example: an API deprecated in 4.1 is supported in 4.2+, 5.x and is dropped in 6.0.
  • A major version contains generally 3 minor versions, released every two months. That means that an API can remain deprecated before being dropped during 6 to 12 months.
  • Any release of plugin must depend on at least the last x.0 version of Sonar API
  • 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.
  • An API is marked as deprecated with:
    • the annotation @Deprecated
    • the javadoc tag @deprecated. The 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:

 

  • No labels