Tracking Issues for Multiple Releases

Pattern:     TrackingIssuesForMultipleReleases
Context:     Multiple versions are being actively developed/maintained. New issues are discovered on one version, and their status and progress needs to be tracked on multiple versions, with minimal overhead but maximal accuracy.
Active versions – active branches where a build was already issued and documented, and new builds are planned.
Problem:     When a new issue is discovered, need to understand start of applicability (when it was introduced into the product) and end of applicability on each version branch (when it was solved). Due to branching, the state might be complex. Tracking the workflow for solving the issue on each branch/version is also complex when working with a naïve model. In addition, managing this can add considerable overhead – unchecked, this can lead to an explosion of bureaucracy and tracking overhead, leading to lack of faithful representation as a backlash.
Forces:     

• Want to accurately visualize the status of each issue on each active version, and whenever new versions are created.
• Want to preserve a relationship between the same issue in the various versions, so progress/understanding from previous work can be reused (reproduction efforts/success, solution, workarounds, etc.)
• Assist project/product management in tracking issues that are active in each version.
• Allow workflow to proceed for each version on a standalone basis (e.g. QA wants to verify issue is closed on all active versions)

Solution:     
When applicability is determined (usually when R&D; analyzes the issue), use Cloning capability in issue tracker to create a new issue for each active version. The clone has all of the data of the original issue, including a clone link to the original issue. The “applicable in version” for the clone should be the active version that the clone was created for. The “Fix for version” should be a milestone/planned version on the same version branch.

Resulting Context:     

• List of open issues for each version lists all issues. No need to calculate list of issues based on input from other versions.
• Workflow can proceed on each version in parallel.
• Naively, even if issue is about to be solved, clones are still created, and will be resolved independently even if based on the same promoted changeset.

Variants: (see below)
Related Patterns:

Pattern:     JustInTimeCloning
Context:     See TrackingIssuesForMultipleReleases
Problem: When working with TrackingIssuesForMultipleReleases, cloning overhead is substantial, and not always necessary. Unchecked, this can lead to an explosion of bureaucracy and tracking overhead, leading to lack of faithful representation as a backlash.
Forces:     

• Allow TrackingIssuesForMultipleReleases
• Want to minimize overhead for reporters, developers, QA verification. Aim to avoid O(N) processing overhead per the number of active versions, whenever possible.
• Separate workflow is needed only for versions which were already delivered to QA.
• Visualizing version contents at this level is needed only when delivering to QA and beyond.
• Need to track which versions contain a fix and which don’t.
• Motivation to merge original fix to all applicable version branches as soon as possible while still in context
• Motivation to focus on version branch you are working on, and avoid the overhead of merging/integrating/testing to other versions.
• For each version, the following might be the case regarding original fix applicability:
• It might apply cleanly or with minor modifications, in which case the motivation is to apply it as soon as possible while still in context, and in which case the need for QA verification is lower (while still required depending on the version state)
• It might not be applicable, and require a whole new solution. In this case the motivation is usually to track the issue as open for the version, and leave it to the appropriate time.
• It might not be applicable, due to irrelevance of the issue on the version (e.g. feature cancelled, whole new behaviour).

Solution:     
Add a “Next version state” field in the issue tracker, with the following options:

• OPEN – issue is open for the next version
• INTEGRATED – a fix for the issue was applied in the next version
• CLONED – the issues was already cloned to the next version so no need to track it here
• UNKNOWN – state in the next version is unknown
• N/A – issue is non-applicable in next version due to irrelevance (see forces above)
• CLOSED – optional. In case QA/others want to signify that the solution was not only integrated but already verified/closed, so no need to do verification once its cloned to the new version.

Lets assume 2 version branches – V1, V2, with V1 currently at V1.10. V2 first build will be V2.1.
When applicability is determined (usually when R&D; analyzes the issue), decide how to proceed with marking/cloning based on the following criteria:

• If the issue was detected on V1 branch, BEFORE V2.1 was created (meaning the version is still only being developed, QA didn’t see it yet, no release notes, etc.), mark the issue as OPEN in next version, but don’t clone yet.
• If the issue was detected on V1 branch, AFTER V2.1 was created (meaning the version is being actively tested, and the contents of each build are being tracked, regression is monitored, etc.), clone the issue to V2, and mark it as CLONED
• If the issue was detected on V2 branch, clone it to V1, since V1 is already being tracked closely.
• Whenever an issue is not applicable to the next version, mark it as N/A in the next version.

NOTE: Most issues on V1 branch will be detected BEFORE V2.1 is created, but several will indeed be detected while both versions are being actively maintained. (Hopefully 80%/20% rule applies here).
NOTE: Issues detected on the newer V2 branch before they were seen on V1 are usually a result of additional QA coverage, or a stroke of luck (another type of QA coverage). This is the minority case here.

When a solution is being integrated to V1, aim to promote it to V2 branch as well. If the issue was cloned, do the relevant workflow for the clone as well. If only marked as OPEN, mark the issue as INTEGRATED in next version.
If a solution was found for V1 but its integration is delayed due to CCB approval or any other process which is heavier for a frozen branch, integrate it to V2 and mark it as INTEGRATED.

When delivering the first V2.1 build to QA go over all issues marked as OPEN on next version (those for which a fix wasn’t already integrated on both V1 and V2) and clone them to V2.
When QA wants to reverify all issues that were integrated, clone all INTEGRATED issues as well, but avoid cloning CLOSED issues (optional)

Resulting Context:     

• Versions already being tracked show the full list of applicable issues and their state
• Versions yet to be tracked will show the full list of issues once tracking is started.
• Overh
  ead of cloning is minimized to the periods of time when two or more versions are being tested/tracked concurrently.