It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Issue tracking on multiple Versions/branches

Deleted user May 22, 2013

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?

5 answers

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?

Exactly the same question as Daniel Holmes.


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

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. 

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).

Suggest an answer

Log in or Sign up to answer
Community showcase
Published in Jira

Jira Cloud for Google Sheets: Automatically Refresh Your Data!

Remember that time you realized it was possible to refresh your Jira data in Google sheets with just one click? What if we told you that you can now get the latest data with no clicks at all?! Zero! ...

7,369 views 33 29
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you