Updates to Sonar’s Community Functionality

Clean Code Sonar Updates
1

Along with the new SonarQube free tier, we’re making some changes to SonarQube Community Edition, which will now be known as SonarQube Community Build. With Community Build, we are accelerating the pace of releases, with monthly builds available to the community (twice as fast as today and more consistent with our cloud offering).

As a result, SonarQube Community Build will adopt a new versioning scheme separate from our commercial versions. Starting with the upcoming release in December 2024, the Community Build will adopt a new Calendar Versioning (CalVer) format. There will no longer be an LTA equivalent version for the Community Build.

Here’s how it works: each release version includes the short year and month and a unique build number, following the format YY.M.0.BUILDNumber.

For instance, the upcoming releases will look like “24.12.0.4234234” and “25.1.0.5234234.” This approach offers a straightforward way to track releases by year and month while maintaining a clear build history, ensuring an easy reference point for versioning progression.

The core functionality of SonarQube Community Build is consistent with the previous SonarQube Community Editions with two exceptions –

  • The .NET analyzer included in SonarQube Community Build will no longer include advanced dataflow bug detection rules. This is consistent with our other flagship languages, where these advanced rules are only available in our commercial offerings.
  • Secrets detection in SonarQube Community Build and SonarQube for IDE will be limited to commonly used secrets. Advanced secrets detection is available in the SonarQube commercial offering, including the new SonarQube free tier.

The features will still be available in the new free tier of SonarQube, hosted in the cloud.

Rest assured, the functionality of the commercial editions of SonarQube has not changed. SonarQube Community Build will be available in December 2024. Learn more about SonarQube Community Build.

3 Likes
2

Currently we are running two instances of SQ, one with the Community Edition and the other with the Developer Edition.
So far, we always updated both instances to the same version to get identical behavior at least for all features available in the Community Edition.
How to get the same correlation between the two instance with the new version schema?

1 Like
3

Hi Lukas,

We run similarly… I was able to go to the github page and select the branch dropdown and could see 10.8.0-24.12-9.9.8, which would be all three covered releases.

It is to bad they didn’t add 24.12 to the docker tags… maybe that will happen in the future.

Good luck out there, Peter

1 Like
4

For instance, the upcoming releases will look like “24.12.0.4234234” and “25.1.0.5234234.” This approach offers a straightforward way to track releases by year and month while maintaining a clear build history, ensuring an easy reference point for versioning progression.

What is the point of including the build number? Is it because it is possible that it will exist two versions starting by 25.1.0, and the build number is required to identify each of them?

If so, why not simply guarantee that there is never two versions starting by 25.1.0?

If not, then what is the point of the build number is the three first digits are enough to identifiy a version?

5

@Philippe_Formulain For what it’s worth, internally we are generally comfortable referring to them as 24.12 and 25.1, especially since we won’t know the build number until the day we release.

6

@Chris or @Colin , could you please help me with my question “How to get the same correlation between the two instance with the new version schema”?

7

Hey @lg2de

While some releases of SonarQube Community Build and SonarQube Server may perfectly align, there’s no guarantee that will always be the case. We (SonarSource) don’t plan to publish a mapping between the versions of SonarQube Community Build and SonarQube Server.

8

Friendly reminder to you commitment https://community.sonarsource.com/t/our-commitment-to-you-and-an-update-on-severity-ratings-for-software-quality/130403: “You, our customers, are at the center of everything we do.”
Currently I do not feel like that…

9

Hi,
I had released sonar-l10n-zh-24.12 for community-24.12 and server-10.8. When I release sonar-l10n-zh-25.1 for community-25.1, what sqs property should I set?

Should I set sqs=10.8 for sonar-l10n-zh-25.1? Or there should be no sqs property for sonar-l10n-zh-25.1?

11

Hi @xuhuisheng,

To be honest, the generation job has (necessarily) changed and I’m not sure what will work and what won’t. Ideally, you’ll specify sqcb=25.1 and omit sqs.

I know you like to have a 1:1 mapping of plugin to SonarQube version, and compatibility of public versions cannot overlap. If you specified compatibility with sqs=10.8 for your 25.1 version, you would have to archive the 10.8 version.

So let’s start from leaving out sqs and if the job breaks, then I’ll apologize for the delay :grin: and raise it internally.

 
Ann

12

I think omit ‘sqs’ is reasonable, because 25.1 might contains some key which server-10.8 didn’t have.

I will create a pull request for sonar-l10n-zh-25.1, and let us have a try.

1 Like
13

Hi @xuhuisheng,

Unfortunately, the job broke. It doesn’t like that LATEST (sqs) is being supported by a version of your plugin that’s not the latest (i.e. the one intended to support sqcb). I believe this is a legacy check from before the product split and have asked to have this corrected.

Unfortunately, we’re at our company off-site next week and a reorg kicking in after that. So it may be some time before we’re able to get to that.

In the meantime, I’ve reverted the commit. The options, as I see them are:

  • just wait (it could be 2w or longer :frowning: )
  • mark your 25.1 version as supporting sqs

Sorry for the delay.

 
:frowning:
Ann

15

Hi @ganncamp ,
I think we can wait for the solution.

There is just a few changes on 25.1. The user can still use sonar-l10n-zh-24.12 with sonarqube-community-25.1. Anyone who want to use sonar-l10n-zh-25.1 can upgrade manually.

If we archive the sonar-l10n-zh-24.12 and mark sonar-l10n-zh-25.1 to support sonarqube-server-10.8, there may be still some mis-matched i18n key.

16

Hi,

Thanks for your patience.

We’ve created a ticket for this, and it’s currently ‘in progress’. I don’t have a concrete ETA for the fix, but I’m hoping for “soon”.

 
Ann