I once wrote a plugin (http://toolsmiths.blogspot.com/2010/04/one-bug-multiple-branches.html) to answer two related questions:

1. Which versions is this bug present in?

2. Which bugs are present in a specific version?

I created a project named Builds. Every build of the software created a Build issue in the project. Build issues were linked to the previous build and the next build. When a version control branch occurred the Build issue was linked to two next builds.

Each bug indicated the builds that it was confirmed present in (affects), and the builds that it was confirmed not present in (fixed). Then the plugin created reports to answer the two key questions by creating a tree of the Builds involved. The nice thing was that discovering a bug in some released build automatically showed the bug as affecting the latest build. This dynamic info was useful.

I'm not really sure why more bug trackers don't support multiple releases better. It's been a pain point in most places I've worked at.

I have seen various attempts to tackle the problem of tracking bugfix releases to multiple branches.

1. Clone the issue for each branch.
   • In one JIRA project or
   • with one JIRA project per branch
2. Use the fix version by adding a dummy version string for each branch that the issue shall be fixed on and replacing it by a real version once the fix is integrated into that version
3. By a custom plugin that creates a set of subtasks on certain workflow transitions. Each subtask will be used to decide whether a fix is to be applied to the branch or not and to track the fix application/verification for that branch (by a quite simple workflow for the subtasks).

Option 3 was of course the one with the highest implementation effort (custom plugin...) but also provided the most clarity and least overhead for all users (project and release management as well as developers). Actually, 2 colleagues and I liked it so much that we wrote an article about it already a while ago. (Sorry, in German).
This way, you also have the requested possibility to have a different (subtask) status per branch.

This feature is really needed.

During the evaluation of Jira, we concluded that it was a very good product yet quite simple to use. Now that we have been using it for over one year, we have found some lacks like this which make us change our opinion. Sorry but in our opinion Jira still misses some basic functionality.

Is there a chance, one day, to have information on whether this functionnality will be implemented or not ?!
This issue is opened for almost 5 years now and it's useless to leave it open if you don't plan to implement it !

For my company, this is THE missing feature that prevents us to adopt Jira... Too bad :x

We really need this feature also since we maintain 3 active versions of our product. I'm in the process of importing our current bug base into Jira and have already reached 65,000 in one product line and 30,000 in another; so it is really not practical to clone 2 extra copies of each bug.

I have to agree with Chris and and Ben. I've tried to think up ways of reusing the Clone feature to provide this functionality, but they all fall short of allowing multiple Fix For Versions for a single issue to be tracked independently. Although I didn't care for ExtraView when I evaluated it, this was one feature they had which seemed very useable (http://www.sesame.com/DefectTrackingTour/NewFieldsforEditing.html).

While I wouldn't recommend reusing the Clone feature, if you did go that route I'd say make sure that we could take a new issue or an existing issue and create multiple clones targeting different Fix For Versions (in potentially different JIRA projects) in a single step or perhas using some sort of wizard. I would also make sure that these clones were all cross linked with each other automatically.

BUT I really would prefer something like ExtraView.

Having looked at the clone feature in 3.4.2 Enterprise I would agree with the previous comment.
Quite freqently we apply fixes to 1 branch / version of a product 1st and then once the fix is confirmed, we'll then implement of the others after that. There's a definate need in our process to be able to track that.

I'd prefer that we can track the status and resolution of each "Fix Versions" entry separately..

In the asbsence of that a modification to the clone capability such that at the point of cloning you get the ability to specify which FIX on versions you want to create new issues for.... so you can do it all in one transaction. Right now you get exactly the same as the previous one, and then you have to go in and edit the newly cloned issue to just be set for the branch you need. This also triggers another notification email as well which folks are finding to be a bit of a pain.

I agree with Ben. A simple clone feature is nice but really its not a long-term solution. To be honest I wouldn't even use the clone feature. More than 50% of our bugs (and I think most people's too) are logged against multiple fix-for's. I don't want to have to clone half of my issues. Then I have two issues representing the same bug, comments on different issues, double the issues show up in a search, its hard to find one bug and then know when and where it was fixed.