Upcoming Changes to New Code Period


I’m using SonarQube 7.9.1 Community Edition and recently requested an improvement to how the New Code/leak Period can be specified.

After doing some more research, I discovered that the leak period concept is in the process of being merged/refactored in such a way that would, if I understand correctly, eliminate the possibility of setting a version or a date as the New Code Period:

On my team, these are essentially the only kinds of value we use for our leak period. Specifying a version (which should probably just be called a “label”), for example, allows us to easily compare against a “moving target” that gets scanned regularly even if it always has the same version label. It’s perhaps especially important to keep version and date options for users of CE, which doesn’t offer branch support.

Can someone on the SonarSource team close to this feature update please clarify the expected new behavior, motivations behind the change, implications for CE, whether or not my class of use cases are considered as valid or irrelevant, and offer any workarounds or plans for addressing these concerns before 8.0 is released?



My company use the New Code Period the same way, so I also would like to hear about the changes and how it will impact our use of Sonar/

If anyone working on this feature will be at this Thursday’s City Tour event in Paris, I’d love to meet and discuss. I will update this thread if I learn anything new.

Much belated update for anyone who was waiting for my follow-up: I unfortunately didn’t learn anything new about the feature or its motivations at last year’s City Tour.

For anyone interested in giving quick feedback on how to improve how the New Code Period works, an official (short) survey was posted here:

(I’m of course choosing “Other” and adding all my thoughts…)

The survey closes in about a week, so please take a couple minutes to respond now if you’re still interested in this topic—thanks!


To be clear, that survey is gathering information for SonarCloud :sonarcloud:. Not (necessarily) SonarQube :sonarqube:.


1 Like

Thanks for the clarification! It wasn’t clear in the post (it has both tags) nor on the survey, but hopefully any compatible decision made for SonarCloud will eventually be applied to SonarQube as well. :wink: