This might be a silly question, but I have read the official documentation and search in the forum, and still unclear to me.
In my java app, with around 150 maven projects we have two releases by year and that is when the version is changed for every project. We also follow Git Flow, using feature branches, develop and main for populating every release.
We have already the code and we are now migrating to Git and Sonarqube, and need to decide how to set New Code. My first approach is to use just Previous Version for all feature branches and develop. We do not care about main. So, my question is if this is valid as long as we just want to analyze in the feature branches the code added in them, and in develop what has been added since the previous version.
This sounds like you’d be best suited for using a New Code Period of reference branch set to develop so that you get the diff between your feature branch and your develop branch. There’s even an analysis parameter you can use (sonar.newcode.referenceBranch) if you want.
For develop, previous version makes a lot of sense.
And, your version is past EOL. You should upgrade to either the latest version or the current LTS at your earliest convenience. Your upgrade path is:
Thank you for answer, Colin. I have tested (not deeply) feature branches setting New Code to previous version and they seem to grab properly the changes in the branch since it was created. What is the actual difference with setting it to reference branch? I am just trying to understand.
Regarding the upgrade, it’s the company Sonarqube. I guess they plan to upgrade it soon, but I can’t do anything.
When using the previous_version new code period, you risk that the first commits to the branch (whatever is analyzed in the first scan) will fall into Overall Code, rather than New Code. Using the reference branch makes sure those commits are considered new code.