Confusion about New Code Defintion with 'Previous Version' and Branches

Must-share information (formatted with Markdown):

  • which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension)

    • SonarQube Version 8.9 (build 43852)
    • Azure DevOps Server 2020 Update 1.1 (on premise)
    • Version control: TFVC
  • what are you trying to achieve
    We have “Main” branch from which we build our releases. We set sonar.projectVersion, e.g. 2.3.0 dynamically during build which works perfectly well. We have another branch derived from Main on which the features for the next version are being developed. For this we also have a pipeline which sets the sonar.projectVersion e.g. 2.4.0 in the same why as the pipeline for the Main branch does. So in Sonarqube we have two branches with different versions under the same project.

The New Code of the branch build should show differences between version 2.3.0 of the “Main” branch and the “Next version” branch 2.4.0.

It seems this is not working and that I have misinterpreted the docs. There it says

Previous Version – Define New Code as any changes made in your project’s current version. This works well for projects with regular versions or releases.Available at the global, project, and branch level.

It seems Previous Version available at branch level does not mean New code differences are calculated between different branches and versions.

It would be helpful if the docs are more clear here. Also it would be good to know how the New code calculation works behind the scenes. And it should be stated which option works for which versoin control system (pre requesites).

  • what have you tried so far to achieve this
    So I guess I in my case (TFVC) I need to


Hi Christian,

My understanding is that using Reference Branch means the differences between the branches are what’s considered New Code and the version number isn’t considered relevant.

Note that in 9.3 we did some work on the reference branch logic (SONAR-15697, SONAR-14929). I can’t guarantee it will fix your situation, but it might help.


Hi again,

Also, this may be relevant:


Hi Ann,
thank you for your feedback!
It seems the sonar-scm-tfvc plugin does not support this implementation currently. We need to discuss how we want to proceed.

Another question about “Previous version” setting. Is this working with TFVC? Can you explain how this works under the covers please? In my tests merging back from our feature to main branch, it seems this does not work for us. Some examples that the new code feature not working for us:

  • Bug calculation not working: Overall 84 bugs existed in previous version, which is still the case in the new version. But the new code tab reports 5 new bugs. But those 5 bugs existed already for previous version and these 5 bugs are out of the existing 84 bugs. Those files have been changed but the none of the lines with the bugs have been changed, even any lines in the near of this buggy code area have not been changed.
  • Same behavior for Vulnerabilities
  • Security Hotspots seems also to be inconsistent: Overall 46 in previous version, in new version 50 overall and 46 on new code (we have not fixed any of them)
  • Coverage: 68k lines to cover overall in previous version, in new version 62k lines to cover on new code (but we changed only a few files)

If TFVC is not working for New Code, how is Sonarqube able to set any new metric for New Code? So again it would be great if you and the documenation could explain this a little bit more in detail.


Hi Christian,

I believe TFVC works in general for new code detection and ought to be okay with a previous_version setting.

Regarding the 'wrong" new issues you’re seeing, we should dig into those cases individually.

For one or two issues can you provide

  • the rule that raised the issue
  • the last-modified date on the issue line, as shown in SonarQube


Maybe things got mixed up because I have also run an analysis on the feature branch before I had run the analysis on the main branch after the merge of the feature branch.
So before I come back to you with detailed issues analysis I will first delete and clean up all analysis results we had so far and try again only with the main branch analysis.

1 Like

I have deleted the feature branch from Sonarqube and I tried to calculate new code issues, measures etc. just with the main branch and the previous version setting. Now it shows a few less errors but still there are issues, security hotspots detected in the new code tab. The affected files have been changed but those lines of the reported issues have not been changed since previous version.

I guess this info will not help very much to identify the issue?

Hi Christian,

No, this doesn’t feel like a lot to work with. Can you also show the blame date on those issue lines? And when your New Code Period started?


Hi Ann,

I was busy in the project with other stuff, sorry. In the meantime I have completely deleted the project in Sonarqube to have a fresh starting point and I have created a new project with new name and key. I did again two analysis, one on the main branch before the merge of feature branch, and a few days later also on the main branch after the merge of the feature branch into main. Note, actually I just merged into a TFVC shelveset and run the build with that shelveset without checking into main (I also did this in my previous attempts, since our feature branch is not ready for main yet). Now the new code shows less issues than in my previous attempts. But the new code issues are still reporting issues that have been existed in the first analysis even those lines did not change, but the files have changed in other lines not related to the issue.
What do you mean with blame date? The annotation date of the affected issue lines that TFVC shows me? Or is there something in Sonarqube where I should see a blame date calculated by Sonarqube which I am not aware of?

Latest change date of the affected issue lines according to TFVC:

  1. issue: 17.04.2014
  2. issue: 09.09.2021
    Since I used a shelveset and did not merge into main finally could change after the merge but I have double checked with TFVC compare local code (with changes from feature branch) against latest main version, there are no changes at the affected issue lines.


It’s possible that this is the problem. To be honest, I don’t know what a TFVC shelveset is, but new code detection relies on SCM data so if you’re doing something out of the ordinary in your SCM operations that could have an effect. Additionally, I have the sense that this may be particularly relevant:

I mean the annotation date. A lot of SCMs call it the “blame” information (although I personally hate that language).


As you proposed we use now the lg2de / sonar-scm-tfvc plugin. Now the new code calculatoin works much better!

Thank you Ann for your time and support!