Strategy for maintenance/LTS branches

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.

Thanks and regards

Hi Christian,

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.

Best Regards

Hi Christian,

I think I know the answer to this, but I’m going to ask anyway :sweat_smile:

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?