SonarSource is happy to announce the release of 8.4, which includes a ton of new security-related rules for multiple languages, hot DB backups, and performance improvements on both the server-side and during the analysis of some languages. More details about these and other juicy new features in the official announcement.
In addition, there are a few other things you probably want to be aware of:
You can now set a reference branch as the New Code baseline for a branch. (MMF-1994)
We no longer include files in the global search index, so re-indexing speeds up significantly. (SONAR-13291)
We’ve improved accessibility by making code coverage information available to screen readers. (SONAR-12911)
As part of enabling hot DB backups, we’ve made a lot of changes in the database for this version. As a result:
There have been a number of deprecations and format changes for id parameters in web services.
There’s a breaking change in the plugin API related to rule ids. (SONAR-3420)
Migration to 8.4 will be significantly longer than usual.
You’ll find more details about 8.4 in the upgrade notes and full details in the release notes. Please open new threads for any questions you have about these or other features.
As a followup, there are a lot of structural changes in the DB for 8.4. Please make sure that for this version, at least, you do the DB maintenance mentioned in the Upgrade Guide.
Specifically,
Oracle Clean-up
Starting with version 6.6, there’s an additional step you may want to perform if you’re using Oracle. On Oracle, the database columns to be dropped are now marked as UNUSED and are not physically dropped anymore. To reclaim disk space, Oracle administrators must drop these unused columns manually. The SQL request is ALTER TABLE foo DROP UNUSED COLUMNS . The relevant tables are listed in the system table all_unused_col_tabs .
Additional Database Maintenance
Refreshing your database’s statistics and rebuilding your database’s indices are recommended once the technical upgrade is done (just before the very last step).
For PostgreSQL, that means executing VACUUM FULL . According to the PostgreSQL documentation:
In normal PostgreSQL operation, tuples that are deleted or obsoleted by an update are not physically removed from their table; they remain present until a VACUUM is done.`
Multiple people have complained of slow analysis performance post-upgrade that has been resolved by this step.