We upgraded from Community Edition version 5.6 to Enterprise Edition version 7.6 and now we have a question about the use of versions and the ‘previous version’ setting of the leak period.
We are using SonarQube for Java, Dotnet for DotNet Core and for DotNet Framework by de msbuild scanner. For all uses we have this question.
In the community edition we used a sonar project for each solution and release version of that solution. Now we are using the Enterprise Edition we want one project key and project for each solution and we thought we could use the version parameter during analysis.
After a few weeks of using the new version (7.6) of SonarQube and redesigning our build jobs and seen some unexpected analysis results, I think we have a wrong idea about using versions during the analysis.
We always have three versions active (production, next release, changes). These currently have version numbers 23.0.46, 23.0.48 and 23.0.50 which we also use for the version parameter during sonar analysis.
Last week we had a red analysis after a change on the 23.0.46 version. Further research showed that it was compared to version 23.0.48. We did not expect this.
We expect that a change on version 23.0.46 would be compared with the latest analysis of version 23.0.46.
Are we doing something wrong with the version numbers or is our assumption indeed wrong?
Hi,
A “red” analysis really depends on the quality gate used in the project. It could be wrong due to a condition that is specifically about the “new code”, or a condition that depends on the overall metrics.
With the leak period set to “previous version”, the “new code” will be all changes since the last time the version was changed. Every time you change the version, you are starting a new leak period.
So if you change the version from 23.0.46 to 23.0.48 and than back to 23.0.46, that last change to ‘23.0.46’ just started a new leak period from 0 - it doesn’t continue from the previous time when you had set that same version number.
You might want to use branches in your use case. One branch for each version active: production, next release and changes. This way you’ll have the history of each branch separately. Make sure they are classified as long lived branches by changing the regex that classifies branches. More info here.
Hoi Duarte, thanks for your answer. It confirms what we suspected. We are now preparing the changes that are needed to use branches. We are using the short living branches strategy for production and next. So the changes reflect our trunk branch on which all changes are committed in our version management system. There the production and next are also short living branches.
