Release notes
These release notes describe the relevant changes implemented for each SonarQube Server’s release version since the 2025.1 LTA version. For a complete list of all changes, see the Full release notes at the bottom of the page.
New and enhanced features
View the release notes for new and enhanced features for SonarQube Server. If you're upgrading from the previous LTA, see 9.9 LTA to 2025.1 LTA release notes: new and enhanced features.
2025.2
Server operation
IPv6 support
SonarQube Server now supports IPv6 addresses:
- For the ZIP installation: all editions.
- For the Docker installation: Developer Edition and Enterprise Edition.
An additional configuration is required. For setup information, see Enabling IPv6 in ZIP installation or Docker installation.
System info and server logs improved
Data Center Edition server logs available from the UI
If you have a Data Center Edition, you can now download the server logs for all nodes by using the Administration > System menu on any node.
Java options in system info more accurate
The system info now includes Java options information:
- For a Developer or Enterprise Edition: for each process (Web, Compute Engine, or Search) instead of globally.
- For a Data Center Edition: for each node instead of only for application nodes.
AI features
AI CodeFix
Support of self-hosted LLMs on Azure Open AI
You can now choose your own Azure OpenAI LLM as the provider for AI CodeFix. See Enabling AI-generated fix suggestions.
Expansion of rules coverage
TheAI CodeFix's rule coverage has been extended across multiple programming languages, ultimately improving code quality and developer productivity with relative ease.
New SONAR_AI_CODEFIX_HIDDEN environment variable
You can now use the SONAR_AI_CODEFIX_HIDDEN environment variable to disable AI CodeFix in SonarQube Server in addition to the sonar.ai.codefix.hidden property.
Analyzers, scanners, languages
New Design and Architecture feature
Through its new Design & Architecture feature, SonarQube Server can now verify the architecture and design of Java, JavaScript, or TypeScript source code by:
- Verifying the code structure against architecture and design patterns.
- Applying cycle detection to detect circular dependencies in your code.
The verification process is as follows:
- You specify in a configuration file your architecture model including architectural constraints.
- SonarQube Server compares your code with your model based on architecture rules. It raises issues when it identifies divergences and when it detects circular dependencies.
For more information, see Design and Architecture.
CFamily analysis
New C++ rule
The following C++ rule has been added:
- S7172: Named methods should be used to avoid confusion between testing an optional or an expected and testing the wrapped value
New Misra C++ 2023 rules in Early Access
New Misra C++ 2023 rules are supported from the Enterprise Edition in Early Access.
To enable the new rules in your SonarQube Server instance, go to Administration > General Settings > Early Access Features.
Note: To disable the Early Access warning, see Disabling the Misra 2023 C++ Early Access warning.
Go analysis
Go 1.23 now supported
SonarQube Server now supports the analysis of Go 1.23 code.
New foundational Go security rules
The following foundational Go security rules have been added:
Vulnerability issues:
- S4423: Weak SSL/TLS protocols should not be used
- S3330: Creating cookies without the “HttpOnly” flag is security-sensitive
- S2092: Creating cookies without the “secure” flag is security-sensitive
- S4507: Delivering code in production with debug features activated is security-sensitive
- S2068: Hard-coded credentials are security-sensitive
- S2612: Setting loose POSIX file permissions is security-sensitive
- S1313: Using hardcoded IP addresses is security-sensitive
- S2245: Using pseudorandom number generators (PRNGs) is security-sensitive
- S4790: Using weak hashing algorithms is security-sensitive
- S6437: Credentials should not be hard-coded
- S5547: Cipher algorithms should be robust
- S3329: Cipher Block Chaining IVs should be unpredictable
- S5542: Encryption algorithms should be used with secure mode and padding scheme
- S5445: Insecure temporary file creation methods should not be used
- S5344: Passwords should not be stored in plaintext or with a fast hashing algorithm
- S4830: Server certificates should be verified during SSL/TLS connections
- S5527: Server hostnames should be verified during SSL/TLS connections
- S4426: Cryptographic keys should be robust
- S2053: Password hashing functions should use an unpredictable salt
Security hotpots:
- S6418: Hard-coded secrets are security-sensitive
- S5443: Using publicly writable directories is security-sensitive
- S5332: Using clear-text protocols is security-sensitive
- S4036: Searching OS commands in PATH is security-sensitive
- S2077: Formatting SQL queries is security-sensitive
Java analysis
The following Spring Java rules have been added:
- S7177: Use appropriate @DirtiesContext modes
- S7178: Injecting data into static fields is not supported by Spring
- S7179: @Cacheable and @CachePut should not be combined
- S7180: "@Cache*" annotations should only be applied on concrete classes
- S7183: @InitBinder methods should have void return type
- S7184: "@Scheduled" annotation should only be applied to no-arg methods
- S7185: @eventlistener methods should have one parameter at most
- S7186: Methods returning "Page" or "Slice" must take "Pageable" as an input parameter
- S7190: Methods annotated with "@BeforeTransaction" or "@AfterTransaction" must respect the contract
The following Spring Java rules have been improved:
- S6856: "@PathVariable" annotation should be present if a path variable is used
This rule will now raise an issue if a method has a path template with a placeholder, but no corresponding@PathVariable
, or vice-versa. - S6809: Methods with Spring proxy should not be called via "this"
This rule will now also check for methods annotated with Spring's@Cacheable
annotation.
Kotlin analysis
Over 80 rules have been rebuilt to support Kotlin 2.0 and the new K2 compiler. As a result, Kotlin analysis is now 50% faster than before this release. Kotlin developers can now not only use Sonar to analyze Kotlin 2.0 and newer, but it also performs better than before.
.NET analysis
Upload of test-related metrics at file level
Projects based on .NET now show test-related metrics at the file level. The SonarScanner for .NET will calculate and pass to the server the per-file metrics of:
- Number of Unit Tests
- Errors in Unit Tests
- Failed Unit Tests
- Skipped Unit Tests
- Duration of Unit Tests
The SonarScanner for .NET will only support the following test reports:
- NUnit
- XUnit
- Visual Studio
.NET rules improved
A secondary location message has been added to the .NET rules.
PHP analysis
The elsif
keyword is now taken into account in the Cyclomatic Complexity calculation.
Python analysis
The following rules are now available to allow you to check performance, maintainability and correctness in your PySpark code in Python and Jupyter Notebook files with SonarQube Server:
- S7181: PySpark Window functions should always specify a frame
- S7182: The “subset” argument should be provided when using PySpark DataFrame “dropDuplicates” method
- S7187: PySpark Pandas DataFrame columns should not use a reserved name
- S7189: PySpark DataFrames used multiple times should be cached or persisted
- S7191: PySpark
withColumns
should be preferred overwithColumn
when multiple columns are specified - S7192: The “how” parameter should be specified when joining two PySpark DataFrames
- S7195: PySpark lit(None) should be used when populating empty columns
- S7196: Complex logic provided to PySpark “withColumn”, “filter” and “when” methods should be refactored into separate expressions
README for local project installation improved
Information about building locally has been added to the README.
New rules to cover OWASP Mobile Top 10
By now providing at least one rule for each of the OWASP Mobile Top 10 categories, with the exception of M4: Insufficient Input/Output Validation, Sonar offers a solution that enables Android developers to assess their applications against the OWASP Mobile Top 10, ensuring they meet industry standards for security.
Issue retrieval and fixing
Issue filters now more compact
The vertical padding of the issue filter conditions has been reduced.
Web API
Deprecated POST and PATCH parameters now logged into the deprecated log file
Whenever a V2 deprecated POST or PATCH parameter is used, a deprecation message is logged into the deprecated log file indicating what is or will be deprecated and from when.
2025.1
Server operation
Java 21 supported for running SonarQube Server
SonarQube Server can now run in a Java 21 environment.
DevOps platform integration
Improvement to BitBucket server onboarding
To improve the import of BitBucket repositories, you can now browse and easily import all the projects from the onboarding page, without any limitation of number.
AI features
Automatic detection of AI-generated code from GitHub Copilot
Knowing if your project contains AI-generated code helps raise awareness of code ownership and code security. To help build this awareness, SonarQube Server can autodetect AI-generated code in projects on GitHub using GitHub Copilot. You can then protect these projects using the AI code assurance features. See the Autodetecting AI code page for more information.
Analyzers, scanners, languages
Faster analysis bootstrap
To improve analysis efficiency, we’ve shortened the time it takes to load the active rules in your quality profile.
PHP analysis
PHP analysis now supports asymmetric property visibility (PHP 8.4).
T-SQL analysis
T-SQL analysis supports the STIG security standard and more language constructs.
VB analysis
VB analysis has 2 new rules.
Upgrade notes
This section contains notes about breaking changes and important updates to be aware of before upgrading. If you're upgrading from the previous LTA, see 9.9 LTA to 2025.1 LTA upgrade notes.
2025.2
None in this release.
2025.1
Update in PostgreSQL support
PostgreSQL version 11 is no longer supported. Supported versions are now from 13 to 17.
SAML configuration update required
When configuring SAML on your SonarQube Server instance with assertion encryption, the response signature must be enforced. You might need to update your SAML configuration:
- If you use SAML with Microsoft Entra, make sure you sign the response by selecting Sign SAML response or Sign SAML response and assertion as the sign-in response. See Step 2 > If you use encryption, enforce response signature in Setup of security features.
- If you use SAML with PingID, make sure you sign the response by selecting Sign Response or Sign Assertion & Response as the sign-in response. See Step 2 > To enable the encryption of SAML assertions in Setup of security features.
In addition, the assertion decryption now requires that you also store the public key certificate in SonarQube Server (not only the private key). Make sure the certificate is stored in SonarQube as follows:
- In SonarQube Community Build, go to Administration > Configuration > General Settings > Authentication > SAML.
- In SAML Configuration > SAML, select Edit. The Edit SAML configuration dialog opens.
- In Service provider certificate, enter the certificate.
Server base URL setup now mandatory for SAML authentication
Your SAML authentication setup will not work if the SonarQube Server base URL is not set in SonarQube Server. See Configuring the SonarQube Server base URL.
Deprecations and removals
This section contains information on the deprecation and removal of SonarQube Server features and API endpoints. See also the deprecation policy.
2025.2
None in this release.
2025.1
Property encryption on scanner side deprecated
Property encryption on the scanner side is now deprecated.
sonar.password property removed
The sonar.password
scanner property that was deprecated in SonarQube Server 9.8 has now been removed.
BCrypt password hashing method removed
The BCrypt hash method used for passwords was deprecated in SonarQube Server 8.9. It has now been removed. As a result, the passwords of users who have not logged in since SonarQube 8.9 are deactivated and an admin must reset them if these users need to log in again.
Some complexity metrics removed
The following complexity metrics, which were deprecated in SonarQube Server 6.7, have now been removed:
file_complexity
complexity_in_classes
class_complexity
complexity_in_functions
function_complexity
function_complexity_distribution
file_complexity_distribution
Full release notes
Links to the full release notes in Jira:
Was this page helpful?