Consider version 2 of a plugin that defines a rule renaming from foo:A to bar:B.
When this new version of the plugin is installed, rule foo:A is renamed to bar:B and all issues of foo:A are kept in the current state (rather than being closed and reopened as new).
Now, consider the user installing back version 1 of the plugin. Next analysis will include issues for rule foo:A but the database contains only issues for bar:B. Those issues will be closed and reopened.
To avoid this, rule renaming should be reverted at startup when installing version 1 of the plugin.
To achieve this, deprecated keys declared for a rule should be stored in DB (this will complete steps performed in
In case of downgrade, the downgrades will be detected as such:
- if rule foo:A can not be found in DB
- but foo:A is the deprecated key of rule bar:B in DB, which id is 1234
- then we must downgrade rule bar:B to foo:A
To do do, SonarQube should at startup:
- rename the rule repository bar to foo and rule key B to A in table RULES for id 1234
- update the RULES.RULE index for id 1234 in the same fashion
- update the RULES.RULE_EXTENSION index for id 1234 in the same fashion
- remove foo:A from the deprecated keys stored in DB for id 1234