Sonarqubes new code feature heavily relies on setting versions on specific analysis.
The problem is that releasing a new version not necessarily happens on the main branch.
If you work e.g. with release branches, the new code feature on master never notices that a new version was set in another branch because sonar runs on the release branch importing this version to sonar.
How is this supposed to work?
Kind regards,
Michael
Hi Michael,
In fact, new code detection only relies on setting versions if you choose the Previous Version option for your project/branch’s New Code definition.
You also have the option of setting a reference branch, in which case:
Any differences between your branch and the reference branch in the clone the scanner has access to at analysis time are considered new code.
I’m not entirely sure what release branches are. I suppose you release to production from a branch? And then later merge that branch into main? In which case, you would need to update main’s sonar.projectVersion after the merge, if you’re using Previous Version as your New Code definition.
Ann
So here is how we work with release branches:
Latest development always happens on main,
If we decide to create a release we derive a branch from main e.g. release/1.0.0
This branch is prepared with some final release changes and the latest commit is tagged as v1.0.0
There is no merge back to master as we would need to revert the final changes in the release branch.
I don’t see a good option how to combine this with the sonarqube new code feature, otherwise than fakeing the sonarqube analysis and override the release branch name to main.
Any suggestions would be appreciated
Kind regards,
Michael
Hi Michael,
Thanks for the explanation. This is pretty much how we work too. I’m not sure there are “final release changes”, but otherwise…
So, the way we do it is:
We’re currently developing the changes that will be released (imminently) in SonarQube 10.3. So with each analysis of main, sonar.projectVersion is set to 10.3.
When it’s time to cut the 10.3 branch - from which any bug fixes would be released 
- then we change the analysis properties to say sonar.projectVersion=10.4.
Since we use Previous Version as our New Code definition on main, then what’s “new” is everything that’s added/edited since the last analysis with a 10.3 version string.
Does that make sense? Help?
Ann
The downside is that we sometimes were lazy on updating the next dev version on master which brings us in trouble here.
I think the best fix is to be more serious on maintaining next dev version on main.
Thanks