Tracking Issues for Multiple Releases

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.