SonarQube Server 2025.1 LTA was released in January, and we hope you’ve seen our announcement and are in the process of upgrading!
A new Long-Term Active (LTA) version of SonarQube Server represents a significant amount of work. Since the last LTA release (version 9.9 in February 2023), thousands of development tickets have been merged into SonarQube Server and its underlying components. This includes new features, improvements to existing functionalities, and bug fixes.
Since not all updates can be included in our major release announcements, I want to highlight 9 exciting features that you might not know are part of SonarQube Server 2025.1 LTA.
#1 - Change the main branch of your project
With the latest LTA release, it’s finally easy to designate a new main branch!
We introduced support for Branch Analysis all the way back in SonarQube 6.7. To put it kindly, branches were somewhat “hacked” onto the existing project component. This meant that there was no real differentiation in the underlying data model between a project and the main branch of a project. The result? It has never been possible to change the main branch of a SonarQube project.
There are many good reasons why a user might need to change the main branch, like when a team adopts a new branching strategy or decides to shift the focus to a different branch, such as a long-lived release branch, to better reflect their current workflows.
Previously, changing the main branch in SonarQube wasn’t just inconvenient—it was destructive. The only workaround involved renaming the existing main branch, which meant one branch carrying the history of two separate branches. If the original main branch was still being used, it had to be created as a new branch.
That’s the past now. Now renaming a branch is just a button click away.
#2 - Deactivate Rules in Extended Quality Profiles
We work hard to make sure every rule included in the built-in Sonar way profiles are uncontroversial: something the majority of developers on the majority of projects would find obvious. However, do you agree with every single rule in the built-in Sonar Way Quality Profiles? Let’s be honest—probably not. And that’s okay.
Maybe there’s a rule or two that just doesn’t fit your project’s needs or clashes with a coding technique you’ve used successfully for years. You’re on board with most of the rules but wish you could deactivate a few without losing the benefits of automatic updates to the Sonar Way profiles as your SonarQube Server receives updates.
Previously, the only way to handle this was to copy the Sonar Way profiles and create your own custom version. But this had a big downside: you then had to manually maintain your custom profile every time the original profile was updated—a time-consuming process most users understandably avoided, leading to static, unchanging Quality Profiles.
SonarQube 2025.1 LTA introduces the ability to extend a quality profile while deactivating specific rules. This means you can now inherit updates from the Sonar Way profile while tailoring it to your project’s unique needs. Add the extra rules you need, disable the ones you don’t, and rest easy knowing your quality profile stays up to date with minimal effort.
#3 - Resolve External Issues
SonarQube makes it easy to import external issue reports from many popular static analysis tools, complementing analysis results. However, until now, managing these external issues was a separate task that had to be handled outside of SonarQube. If you wanted to “Accept” the issue or mark it as a false positive, you had to return to the source tool to suppress it.
Not anymore! With the latest LTA release, SonarQube allows you to manage external issues just like native ones.
#4 - Track SonarQube Updates on the Activity Page
Have you or a project stakeholder ever noticed a sudden spike or drop in issues or measures and wondered, “What changed?”
One often overlooked cause is an upgrade to SonarQube itself, which can introduce new rules, improve existing rules, or even introduce new analysis capabilities that widen the scope of analysis.
With the latest LTA release, SonarQube makes it easy to track these changes. The Activity tab of each project now displays an event whenever an analysis is the first one after SonarQube has been upgraded. This simple addition provides some valuable context for understanding shifts in your project metrics.
#5 - Grace Period for Server ID Changes
Migrating a SonarQube instance to a new server or infrastructure can be stressful enough without worrying about your license becoming invalid in the process. In the past, if your Server ID changed – because you took an action that changed the Server ID (like changing the hostname of your database server), you needed to get in touch with Sonar to obtain a new license.
Now, with SonarQube Server 2025.1 LTA, we’ve introduced the ability to activate a grace period when your Server ID changes. This means your license remains temporarily valid, giving you some breathing room to complete your migration without interruption.
This grace period can only be used once, so it’s important to ensure your new Server ID is stable and final before making the switch. This one-time flexibility minimizes downtime while ensuring the integrity of your license.
#6 - Log deprecated API usage
As SonarQube evolves, so does its API. Over time, existing scripts and automations—built with previously valid calls—can end up relying on API features that are later deprecated.
To help you stay ahead of these changes, the SonarQube Server 2025.1 LTA introduces logging for deprecated API usage. Now, whenever a deprecated API is called or a deprecated parameter is used, SonarQube generates a clear warning in the logs, including details about when the parameter was deprecated and its planned removal.
For example:
2025.01.25 17:16:54 WARN web[053defff-65e4-4d38-b240-8ad37f8d491a] /api/system/logs Parameter 'process' is deprecated since 10.4 and will be removed in a future version.
This new feature gives teams the visibility they need to update their automations long before breaking changes occur. Instead of having to fix things at the last minute when planning an upgrade, you can address these changes on your own schedule.
And no, we definitely didn’t add this feature to make sure we aren’t using deprecated APIs ourselves in SonarQube. 😉
#7 -Track Users’ Last Connection to SonarQube for IDE
The earlier issues are fixed, the better. Fixing them before deployment is good, catching them before a merge is better, but identifying them before a commit? That’s the gold standard. That’s where SonarQube for IDE (formerly SonarLint) comes in, helping developers address issues directly in their IDEs as they code.
To help organizations track the adoption of SonarQube for IDE, you can now view when a user last connected to SonarQube for IDE (in the UI and via the Web API) This visibility makes it easier to assess how widely connected mode is being used across your teams—and nudge developers who might not yet be taking full advantage of it.
This feature isn’t just about metrics; it’s about fostering better coding practices. By encouraging early issue detection, teams can save time, reduce merge conflicts, and improve the quality of their software from the ground up.
Of course, with great power comes great responsibility! Use these insights thoughtfully to support developers, not micromanage them. After all, the goal is to help teams fix issues sooner, not add unnecessary pressure.
#8 - Suppress New Issues in SonarQube for IDE Before They’re Raised on SonarQube Server
We’re not done talking about SonarQube for IDE.
With SonarQube Server 2025.1 LTA, users can now suppress issues flagged by SonarQube for IDE before they make it to SonarQube Server. Whether you want to mark an issue as “Won’t Fix” (now called Accept) or as a False Positive, you can do so directly in your IDE.
This was previously only possible once an issue had been raised in SonarQube Server—now, you don’t have to wait until the analysis is submitted to sift through the results for issues you already know you aren’t going to fix. If you suppress an issue in SonarQube for IDE, it won’t show up again later.
This feature is supported for IntelliJ, VS Code, and Eclipse
#9 - JRE auto-provisioning
If you’ve ever had to scramble to update your CI pipelines or local environments because SonarQube bumped its Java requirement, you know the pain. The jump from Java 8 to 11 in SonarQube 9.0 was a particularly memorable challenge.
We have to upgrade to newer Java versions for our developers to use new features, reduce headaches, and stay innovative. But we know this can be a pain for you, especially when managing hundreds of CI pipelines.
And guess what? We’ve updated the requirement again to Java 17. However, this time, most of our users didn’t notice!
SonarQube Server 2025.1 LTA introduces JRE Auto-Provisioning. Instead of requiring you to manage the right Java version in your pipeline, SonarQube now spins off a new Java process with a JRE downloaded from your SonarQube server. That means you can leave your Java 11 build alone. Just make sure you’re using a version of the SonarScanner that supports this feature.
We really hope that most users will never have to think about what version of Java is required by the SonarScanner again.
Just an upgrade away from it all
If you haven’t tried SonarQube Server 2025.1 LTA yet, I hope you now have 9 more reasons to prepare that upgrade with your team. This is a free version upgrade for all, and you can get the LTA in just a few clicks @ SonarQube Server Downloads.
Need more help getting started? Check the following resources:
- SonarQube Server Upgrade Documentation
- SonarQube Server LTS Upgrade Checklist
- Get help upgrading in the Sonar Community