Migrate Polyspace Projects After Product Upgrade

This topic describes how to migrate existing Polyspace^® projects or configurations to a new release of Polyspace. For migrating Polyspace Access results databases to a new release of Polyspace Access, see Install Update or Upgrade to New Version of Polyspace Access (Polyspace Access).

When you upgrade your Polyspace products to a newer release, you have to migrate existing projects to this release. In general, migrating older projects to a newer release can be as simple as opening them in the user interface of the newer release. For instance, if a Polyspace analysis option has changed name between releases, the change is automatically handled in the user interface of the Polyspace desktop products.

However, each newer release of Polyspace provides new options, improved results and better user workflows. When you upgrade to a newer release, you might have to account for these changes.

Account for Changes in Options

The user interface of the Polyspace desktop products handles most changes in analysis options. However, there are certain situations where you might have to explicitly update options. For instance, if you enter a command-line-only option in the Other field of the analysis configuration and the option is deprecated in a later release, you have to explicitly remove the option.

If you run an analysis at the command line, you have to explicitly update options as needed.

Step 1: Rerun Analysis

To see which options have been removed in the current release (and not automatically handled in the user interface):

Open your project in the user interface of the current release.
Rerun the analysis and check the messages on the Output Summary pane:
- Options that will be removed in a near release trigger a warning.
- Options that are removed trigger an error and stop the analysis.

If you are running an analysis at the command line, the same errors and warnings appear in the analysis log. See also View Error Information When Polyspace Analysis Stops.

Step 2: Update Options

An option might be replaced by an alternative or removed altogether because it is no longer required. An option typically changes the default behavior of the analysis. So, if the default behavior itself changes in a new release, the option might no longer be required.

Messages on the Output Summary pane only state if an option will be removed in a near release or has already been removed. To understand why option has been removed and what the option has been replaced with, check the product release notes:

All changes in options appear each release in a release note entry titled Changes in analysis options and binaries. Check this entry to see if the option is replaced by an alternative or no longer required.

If the option is replaced by an alternative option, change the option to the new one.
If the option is no longer required, remove the option from your analysis configuration.

Account for Improvements in Results

Newer releases of Polyspace are, in general, more precise than previous releases. This means that for the same source files and analysis options, you might see a difference in results. For instance, a Polyspace Bug Finder™ analysis might no longer show a certain kind of false positive from previous releases.

Before migrating several projects, sometimes, you might want to perform a test migration of one or a few projects to gauge what result changes to expect after migration. This test migration can help you anticipate changes to expect after full migration.

Step 1: Compare Results

You can follow this process to compare the results of a project in two different releases:

Run analysis on the same project in both releases.
- If you use the Polyspace desktop products, run analysis on the same project (.psprj file) in the user interface of the two Polyspace releases.
- If you use the Polyspace server products, run analysis using the same scripts changing only the paths to the Polyspace binaries in the two runs.
After the analysis completes, check the log for any unexpected warnings. For instance, Polyspace might warn you that the new release contains checkers that are not available in the older release.
Note that you can compare two runs and attribute all changes to the product upgrade only if the source code and analysis options are the same. Make sure that your sources or options have not changed between the two runs. Some option changes might be necessary in the newer release but these changes can only remap older options to new ones (or remove redundant options). See Account for Changes in Options.
Compare the two sets of results and find which results have changed. To compare two sets of results in the Polyspace desktop user interface:
1. Open the newer set of results.
2. Select Tools > Import Comments and import from the previous set of results.
3. After the import, click the New button.
Results that remain are the new ones in the current analysis. For details on comment import, see Import Review Information from Previous Polyspace Analysis.
To compare two sets of results in the Polyspace Access™ web interface:
1. Upload both sets of results to the same Polyspace Access project. You can upload using the polyspace-access command or from the Polyspace desktop user interface.
2. Use the run comparison feature in Polyspace Access to compare the two uploaded results. See Compare Results in Polyspace Access Project to Previous Runs and View Trends (Polyspace Access).

Step 2: Interpret Changes in Results

For the same source code and analysis configuration, you might see a change in results because of improvements to the analysis engine. See Understanding Changes in Polyspace Results After Product Upgrade.

To account for changes in results, you might want to do one or more of the following:

Remove redundant code annotations.
If you had entered code annotations justifying results that no longer show up, you might want to remove the unnecessary code annotations. Code annotations that no longer apply show up as warnings in the analysis log. See Code Annotation Warnings.
Update quality gates or objectives.
Sometimes, a change in checker specifications or analysis precision might affect several results of a certain type. To adapt to this change, you might have to update your quality gates or objectives. For instance, if you had earlier required that only red Illegally dereferenced pointer Code Prover checks must be fixed or justified, you might now want to include orange checks in your requirements.

If you are running Bug Finder, you might also want to enable new checkers after a product upgrade. These checkers might be newly available in the current release or have fewer false positives compared to previous releases. Check the Analysis results section of the Release Notes for Polyspace Bug Finder for new and updated checkers.