What is the suggested best practice for being able to track porting activities across releases?

Shawn Badinger

What is the suggested best practice for being able to track porting defects across releases? We have tried both of these:

(1) cloning a bug to other release(s) - cleaner for the teams receiving ported code, but not easy to track in the original release, and can create confusion with the multiple JIRA defects.

or

(2) adding tasks to the original JIRA bug to have it ported to 1 or more other releases - really hard to track in the other releases, but easier for original team to ensure it gets done as they cannot close the bug until all tasks complete

There has got to be a better way both for execution and for tracking!

Thanks, Shawn

Kim Poulsen

Is this all hapening in the same Jira project?

If so, why not use the "affected version" field for tracking in which version(s) the defect was found, and use the "fix version" when it is fixed.

Filters on e.g. a dashboard can then find issues which were discovered in a certain version and show their status (open/closed).

The issue will live on with the affected version field updated for each release it survives until it is resolved.

If you have multiple projects - one overtaking the next - as in one project per release you can 'move' the issue to the next project. The original issue link (PROJ1-1234) will still work for the new issue (PROJ2-94) even though the key changed.
If you have one project per release do consider making it one (JIRA) project as it will make life easier when issues are related to the same code branch/product.

Regards, Kim