Skip to main content

How-to Handle Bugs in Multiple Releases

A bug can exist in multiple releases, and such bugs can be challenging to track and fix. This guide describes how to manage them.

Together with other bug-related guides, it provides information to help ensure correct handling of all types of bugs. It relates to PCP R&D’s overall bug management process, described in How-to Manage Bugs, as visualized below.

MB-G

Note: This guide focuses on bugs existing in multiple releases of the same product, it does not cover common components reused in multiple products or systems.

Intended for​

Product owners and configuration managers.

Activities​

Activities

Discover if a bug exists in multiple releases​

It may be tricky to discover if a bug exists in multiple releases. When a bug is reported, it is a good practice to try to find out whether this bug existed in other releases.

Sometimes it is easier to find out, sometimes it may be more time-consuming and it can be considered as too much effort.

When fixing the bug, the developer may notice that the code where the code fix is necessary exists in other versions, so the bug may exist in other versions too.

When working on a maintenance release, it may be discovered that the bug exists in newer releases.

Clone bug to affected releases​

For each release/version/track (that is still in an active state according to the product's lifecycle policy) in which the bug is known to exist, clone the bug as described in the procedure below. If the bug exists in a large number of releases, the change control board (CCB) decides where it makes sense to clone it and writes this information in the bug discussion.

Note: Steps 1-5 are automatically performed if the "Clone Bug" extension is installed, see Recommended Extensions. The extension is triggered automatically when saving a bug with the state "Closed" and reason "Deferred". You can also perform the steps manually by clicking on "Clone as duplicate".

  1. (Automatic) Clone the bug.
  2. (Automatic) Add "Clone of bug ID -" to the title.
  3. (Automatic) Set "ScopeBug" = "true" in the clone just created.
  4. (Automatic) Set "Cloned" = "true" in the clone just created.
  5. (Automatic) Add a link of type "duplicate"/"duplicate of" between the original bug and the clone.
  6. (Manual) Set the target release, see Area and Iteration Path.
  7. (Manual) Check that the "How found" field is properly filled in ("Post release" for backporting and "Forward Port" for forwardporting).
  8. (Manual) Save the cloned bug.

Cloning the bug in this way follows the same strategy as bug deferring. This method allows to associate bugs that are copies of each other and belong to different releases.

Track decisions, planning, fixes and validation for each release​

From now on, follow the normal bug management process, see How-to Manage Bugs:

  • The CCB can decide to fix the bug, ensuring it will be planned, fixed, and validated (including fulfillment of DoR and DoD).
  • The CCB can decide to acknowledge the bug but not to fix it, i.e. set the reason to "Will not fix" (see How-to Handle Deferred Bugs).

Transfer the bug fix across different releases​

When possible, merging the bug fix to the branch of the target release can be an efficient way to transfer the bug fix. However, this may require additional effort, for example, if the code on the target branch is significantly different and several complex conflicts occur. The fix and the impact on different branches can be different, so also tests to validate the bug fix can be different.

Find all the releases where the bug is known and where it is fixed​

Make a tree query based on the duplicate/duplicate of link type (instead of parent/child) to show all the known instances of a bug in a tree query.

For each known instance of the bug, the state and other information can be visualized in the query, showing where it is fixed, where it is planned, and where it will not be fixed.

DT example

Details​

About bugs in multiple releases​

A bug can exist in multiple releases for different reasons, for example:

  • A bug was deferred for some releases before being fixed, see How-to Handle Deferred Bugs.
  • A bug was found after the release.
  • A bug was found during internal tests before release, but the code containing the problem existed in past releases too.
  • A bug that did not appear before can be discovered due to a change in the code or an environment change.

The “bug in multiple releases” concept applies to releases that have been officially released to customers and internal releases, still under development.

About back- and forwardporting​

Depending on where the bug is first discovered, the process of fixing the bug can be referred to as:

  • Backporting: fixing the bug in an older version.
  • Forwardporting: fixing the bug in a newer version.

Backporting does not apply to hardware.

Forwardporting is highly recommended, otherwise, a bug fixed in a previous version may re-appear in a newer version and result in a regression bug, see Regression Bugs.

When planning to port a bug already fixed in a release to a different release, the effort of all the necessary activities needs to be taken into consideration, for example, fixing code, testing, and updating documentation. Even in the case where the fix is a simple merge with very few conflicts and the test itself is quick, preparing the environment and the preconditions for testing can take a significant time.

References​

Owner: Configuration Management Team