JIRA
  1. JIRA
  2. JRA-1493

Allow issue to be in different fix status for different versions

    Details

    • Type: Improvement Improvement
    • Status: Open (View Workflow)
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.0.2
    • Fix Version/s: None
    • Component/s: Issue Fields
    • Labels:
      None

      Description

      I've created an issue with a Fix For Version 1.7.3. I've edited it to have two Fix For Versions, 1.7.2 and 1.8. Than I solved the issue in 1.7.3 only.

      The issue only shows up in the Road Map's version 1.7.3, but not in 1.8.

        Issue Links

          Activity

          Hide
          Gilles Figoni added a comment -

          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

          Show
          Gilles Figoni added a comment - 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
          Hide
          David Ruana added a comment -

          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.

          Show
          David Ruana added a comment - 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.
          Hide
          Abuzer N added a comment -

          This feature is really needed.

          Show
          Abuzer N added a comment - This feature is really needed.
          Hide
          Tobias Rodenbach added a comment -

          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.

          Show
          Tobias Rodenbach added a comment - I have seen various attempts to tackle the problem of tracking bugfix releases to multiple branches. Clone the issue for each branch. In one JIRA project or with one JIRA project per branch 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 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.
          Hide
          Matt Doar (ServiceRocket) added a comment -

          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.

          Show
          Matt Doar (ServiceRocket) added a comment - 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.

            People

            • Assignee:
              Unassigned
              Reporter:
              Thomas Singer
            • Votes:
              41 Vote for this issue
              Watchers:
              36 Start watching this issue

              Dates

              • Created:
                Updated: