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: