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 8 Next »

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 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(For instance 5.1, 5.2, 5.3 -> which becomes 6.0 after several weeks and bug fixes, 6.1, 6.2, 6.3 -> which becomes 7.0 after ...). That means that an API can remain deprecated before being dropped during 6 to 12 months.
  • Any release of Sonar plugin must at least depend on the last major x.0 version of 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:

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

 

  • No labels