• We collect Jira feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      We have been using and depend on version hierarchy for as long as we've used Jira/Greenhopper/Agile (about 3 years now). It continues to work for now but I keep seeing references saying the Classic Board is going away. The only thing we still use on the Classic Board is defining the version hierarchy as we add new versions. I typically get a page timeout when I navigate to the Classic Board so I can only assume it's seldom used.

      I'll explain our release cycle to give context. We release a major product version every 4 months (version 21 is active and 22 is under development). Each product version cycle contains about six 2 week feature sprints, several hardening sprints, release/upgrade for customer instances, and then about 4 to 7 patches to production instances until that major version gets replaced with next major version. We have a unique minor version number for each of these builds/releases that is a child to the major version number.

      Without version hierarchy, a whole bunch of our filters that reference parent versions will stop working and become impractical. In other words, these queries would need to reference many versions instead of just the parent version. In addition, we often target issues first to a major release and subsequently to a child version (release build) as the more detail planning occurs. Without the version hierarchy, this practice will most likely become overly complex and no longer work. Yes, we do use Agile boards but mostly for high level enhancement/feature planning and not for all the defects and other gritty details.

      Is the version hierarchy capability and behavior going to be migrated to core Jira? still part of Agile? Now that sprints and fixVersion have been separated it seems logical to move it to core Jira. I sure hope version hierarchy doesn't just disappear one day when Atlassian puts a new release out to AOD.

      I've dug through the documentation (and Answers) and all I see is statements saying the Classic Board is going away. That's fine as long as the current version hierarchy behavior continues to be supported. Can I get a definitive answer as to the product plans related to this.

          Form Name

            [JSWSERVER-11048] Need version hierarchy after Classic Board goes away

            So how much time do we have before version hierarchy disappears from AOD/Jira Cloud? From, https://confluence.atlassian.com/display/AGILE/The+Future+of+JIRA+Agile, it only gives a relative time measure. But what I need in order to figure out a game plan is a date (or a fairly small date range).

            Joel Heinke added a comment - So how much time do we have before version hierarchy disappears from AOD/Jira Cloud? From, https://confluence.atlassian.com/display/AGILE/The+Future+of+JIRA+Agile , it only gives a relative time measure. But what I need in order to figure out a game plan is a date (or a fairly small date range).

            joel.heinke@veevasystems.com, thanks for you comment, as noted above version hierarchy will not be added to the boards.

            There are a number of add-ons available which may be of use:

            Search Intent to help filter issues based upon their parent/child relationship - https://marketplace.atlassian.com/plugins/com.atlassian.jira.plugins.jira-search-intent-plugin

            Misc workflow extensions - to copy values to a parent issue.
            https://marketplace.atlassian.com/plugins/com.innovalog.jmwe.jira-misc-workflow-extensions

            Regards,
            Martin
            JIRA Agile

            Martin (Inactive) added a comment - joel.heinke@veevasystems.com , thanks for you comment, as noted above version hierarchy will not be added to the boards. There are a number of add-ons available which may be of use: Search Intent to help filter issues based upon their parent/child relationship - https://marketplace.atlassian.com/plugins/com.atlassian.jira.plugins.jira-search-intent-plugin Misc workflow extensions - to copy values to a parent issue. https://marketplace.atlassian.com/plugins/com.innovalog.jmwe.jira-misc-workflow-extensions Regards, Martin JIRA Agile

            Martin,
            I don't think what we need is covered in GHS-9237 at all.

            The main current behavior that we need is the automatic fill of the parent version value in the FixVersion field when a child version is entered. The reason for this is we have many filters that use the parent version value to pick up all the issues from the many sprints (each having a child version) and patches for each of our releases. So if the version hierarchy goes away this will require people to manually enter both the child and parent versions when they enter a FixVersion value. If they forget to enter the parent version, that issue will not be picked up by the filter referencing it's parent version when it should be.

            It's not practical to enter all the child version values in these filters because it's not predictable how many child versions are needed (especially in the patch scenarios) and what they will be named. In addition, version values cannot be entered into a filter until they actually exist.

            Please let me know if our use cases swings the decision back in our favor. If not, what are our alternatives? Are there any plug-ins that provide a similar version hierarchy? I hope so, otherwise having key behaviors simply go away is like having the rug pulled from under your feet

            Thanks,
            Joel

            Joel Heinke added a comment - Martin, I don't think what we need is covered in GHS-9237 at all. The main current behavior that we need is the automatic fill of the parent version value in the FixVersion field when a child version is entered. The reason for this is we have many filters that use the parent version value to pick up all the issues from the many sprints (each having a child version) and patches for each of our releases. So if the version hierarchy goes away this will require people to manually enter both the child and parent versions when they enter a FixVersion value. If they forget to enter the parent version, that issue will not be picked up by the filter referencing it's parent version when it should be. It's not practical to enter all the child version values in these filters because it's not predictable how many child versions are needed (especially in the patch scenarios) and what they will be named. In addition, version values cannot be entered into a filter until they actually exist. Please let me know if our use cases swings the decision back in our favor. If not, what are our alternatives? Are there any plug-ins that provide a similar version hierarchy? I hope so, otherwise having key behaviors simply go away is like having the rug pulled from under your feet Thanks, Joel

            Many thanks for reporting this issue, however, version hierarchy will not be implemented in the Agile boards.

            The linked issue GHS-9237 or a similar multiple-version report would likely cover your needs. Please let me know if you think this is not the case.

            Regards,
            Martin
            JIRA Agile

            Martin (Inactive) added a comment - Many thanks for reporting this issue, however, version hierarchy will not be implemented in the Agile boards. The linked issue GHS-9237 or a similar multiple-version report would likely cover your needs. Please let me know if you think this is not the case. Regards, Martin JIRA Agile

              Unassigned Unassigned
              741358e2c38e Joel Heinke
              Votes:
              1 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: