Hi,
I wondered if there is any good practice on how to handle maintenance/LTS branches.
As quality profiles and gates are assigned on a project level, future changes there will also affect these branches.
This is in most cases not desired as many new sonar issues will appear on the maintenance/LTS branch.
e.g. later in the project the coverage requirement is set to a stricter value. You would then need to fulfill this also when a bugfix on an maintenance/LTS is done. Same when new rules are activated in the profiles. It would be insane to fix all occurences on a maintenance/LTS branch.
How should this be handeled? Or did I miss something?
P.S. We have purchased a developer edition license.
Is there any reason you couldn’t adopt a Clean as You Code approach here and only fix the issues that are raised on new code/changes in these branches?
Hi Ann,
thanks for the reply.
The “Clean as You Code” approach is perfectly fine for the actual changes on a LTS branch (e.g. bugfixes needed for a patch release).
The problem is the reporting. With every release we are forced to report the overall code metrics to our customers. An when in the meantime the quality-profile or -gate have changed (towards more restrictive) we are in real trouble.
I think I know the answer to this, but I’m going to ask anyway
New issues raised immediately after an upgrade are backdated, so they don’t show up as “new” issues. Does that help at all, or is this purely about the raw numbers?
