Issue tracking on multiple Versions/branches

[Deleted user]

We have one product which we maintain about 6 versions of (each on a separate branch in Git).

When filing a bug, we want ONE issue in which we describe the product bug itself (how to reproduce, effects etc).

We want something else to represent the fix of the bug on one Version/branch, in order to be able to keep track of in which Versions/branches we have merged the correction.

(Most often it is one and the same team that handles the correction of the bug on all relevant branches, but sometimes the correction is not done to all branches at once)

We use Git in Stash and want to make use of the power of tying Git commits to our Jira issues.

What would be the best approach for us in Jira?

Our initial idea was to use an Issue of type Bug for the product bug, and a Sub-Task to represent a fix on a specific Version/branch.

The drawback that we find with that approach is that the Sub-Tasks cannot be scheduled in individual Sprints.

Another approach would be to use an Issue of type Bug for the product bug, and one Child Issue of type Bug to represent a fix on a specific Version/branch. The drawback is that the relation Child-Parent is not as obvious as Issue-Subtask, but the advantage is that we can schedule Childs individually.

Is one of these approaches better than the other for us, or are there other approaches that would be even better?

[Jared Murphy]

Hi,

I'm very interested in a solution to this.

None of the proposed workarounds sound very appealing. It would be great if Atlassian could give this some attention, and maybe link us to a work-in-progress feature that addresses this issue?

This cannot be a rare use case...

[zhouzb]

I think I have the same problem.

[Dante]

Hello,

it's 2020 and I am still interested in an answer to that problem.

Clones are not feasible.

Thank you

[Bill Latham]

Just a suggestion -- since Epics can straddle sprints/versions, abstracting this up one level, where an Epic is actually the "parent" bug, and issues in that epic are the version (or sprint) specific instances of the bug being fixed/checked-in, this gives you an easy way to group them together without the restrictive parent-child relationship of issue/sub-task.

Another drawback of doing issue/sub-task for this kind of work is estimates entered on sub-tasks rolling up to the parent (which admittedly can be turned off) become a little meaningless when you're not in sprints and the individual issues aren't being worked on at the same time.  Using an epic bypasses this.

It would be great if the Epic screen (with its ability to show its linked issues) could be categorized into Epic types allowing more than one Epic type (Bug Epic anyone?), but don't know how much support there would be out there (particularly for more strict agile-adherents).

[David Macaskill]

We are cloning tickets. one ticket for each branch. The first ticket represents the main fix to mainline; all the clones represent the propagation to different branches. The only reason we are doing this is so we can track the testing we need to do. Because we support our product in the field for several years, there are multiple versions out in production. We need to know where a fix is, and where it is not. 

[Sophie DK]

Hi, 

Today it is my turn ! Please be so kind to share with me the solution you finally put in place. Thanks, Sophie

[marco.molteni]

Exactly the same question as Daniel Holmes.

[Daniel Holmes]

We are starting to look at JIRA and have the4 same question.  I see this question is a few years old so I'm wondering what approach you ended up utilizing and how is it working?