This is the expected behavior. SonarQube doesn’t change tags and priorities of the created issues. Why? Because you can change them manually. For example, you think that something is very important. Default severity is minor, you changed it blocker and you still want to see it as the blocker after a next analysis. The same situation is with rules priorities in quality profiles. If you activate rule with default major severity, and after an upgrade, the default severity is changed to a minor, then still rule is activated with major. Why? Because your team can think that this rule is more important, so SonarQube won’t change it.
The main problem is that “new issues” will be detected as code smells, but older ones are still bugs. So this lead to a misunderstanding. I understand that you may want to keep the rule as a bug, but then it should detect new issues as bugs to be coherent, and it shouldn’t detect them as code smells.
In the case that the type of the rule did change in the past (e.g. from bug to code smell), then this is in fact expected behaviour. If a new plugin version changes the type of a rule, then existing issues of that rule will not be updated, only new issues (found afterwards) will have the latest type.
The behaviour is like that for good reasons, which you could qualify as ‘reduce noise and impact’: if all issues types would be updated (e.g. for a rule changing from bug to code smells), then your developers would see a sudden increase of Bugs after analysis, although the code might have not changed much. This could be badly perceived, could undermine trust in the tool, and more generally speaking it would create a confusing history timeline, with sudden drops and spikes in various measures.
A quick note on the potential impact: the general recommendation is to focus on New Code (Fixing the Water Leak), therefore focus on new issues, which de-facto have the latest/accurate type (potentially checked in your Quality Gate).
To your question then Antonio:
It’s all about historical data, and the fact that rules/types may have been different in the past, and the history of such a project needs to remain as consistent as possible (per above), contrary to a fresh new project which can directly be based on all latest data.
If SonarSource says that’s ok, then for me it’s ok, but as you said, this could be badly perceived, could undermine trust in the tool, and would create a confusing sense of “what is this? a bug or a code smell? the tool is confusing”.
Advanced users should be ok with this behaviour (they focus on the leak and they just use SonarLint), but maybe the newbies are confused (or even managers).
We think it’s better to tell your users that the quality profile is going to change, give them all the details (rules that no longer exists, rules that will be replaced with new ones, severity changes and issue type changes) and then make the change.
But if you still think that this is the expected behaviour, then it’s ok. We just wanted to check if this was a bug or a feature
