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

      In my team, currently we have a single product deployed in multiple regions. The application has 3 deployment units, each with independent major version, controlled by the PM committee - these are our top-level versions. Every time we produce a binary package for handing over for testing/deployment (few times a month), it gets assigned a version from external system - these are our child-versions (usually we use a xxx-NEXT as temporary name and rename it to xxx-4.0.107 on release). Since recently we started modeling timeboxes (sprints) as third level versions, nested under binary packages.

      Here the problem begins - sometimes we spend multiple iterations to complete a feature, released as a binary package, sometimes within a single iteration we release multiple binary packages.

      To complicate the matters even more, the system is targeting multiple regions. Each region has scheduled deliveries and we model them as (guessed already?) - versions. This worked nice before we started using GH, as in plain JIRA we can assign a particular issue to multiple versions, and by this we can easily express that it's applicable to multiple region and communicate when it will become available.

      There is value in using versions for the binary packages as that's how developers communicate the changes to the deployment teams. There is value in using versions for timeboxes, as that's how GH works. There is value in using versions to outline the deliveries for multiple regions, as this is what the business users are interested in tracking.

      The problem: the GH version-hierarchy accepts only one leaf-level version and once we assign a version from the GH planning board it strips all other versions.

      Proposal: have the planning board calculate the difference in the hierarchy when we move versions and not to remove unrelated versions. For example, if we move an issue from 1.2-M4 to 1.3-M1, the difference is: remove 1.2-M4, remove 1.2, add 1.3, add 1.3-M1 - leave the rest intact. If we need the current GH behavior, we can still easily achieve it by manually synchronizing a version.

            [JSWSERVER-2561] Make GH friendlier to multiple leaf-versions

            Katherine Yabut made changes -
            Workflow Original: JAC Suggestion Workflow [ 3067894 ] New: JAC Suggestion Workflow 3 [ 3661797 ]
            Status Original: RESOLVED [ 5 ] New: Closed [ 6 ]
            Owen made changes -
            Workflow Original: Confluence Workflow - Public Facing v4 [ 2623128 ] New: JAC Suggestion Workflow [ 3067894 ]
            Rachel Lin (Inactive) made changes -
            Workflow Original: JIRA PM Feature Request Workflow v2 - TEMP [ 2323177 ] New: Confluence Workflow - Public Facing v4 [ 2623128 ]
            Status Original: Closed [ 6 ] New: Resolved [ 5 ]
            Katherine Yabut made changes -
            Workflow Original: JIRA PM Feature Request Workflow v2 [ 2041393 ] New: JIRA PM Feature Request Workflow v2 - TEMP [ 2323177 ]
            Katherine Yabut made changes -
            Workflow Original: JIRA PM Feature Request Workflow v2 - TEMP [ 2031603 ] New: JIRA PM Feature Request Workflow v2 [ 2041393 ]
            Katherine Yabut made changes -
            Workflow Original: JIRA PM Feature Request Workflow v2 [ 738312 ] New: JIRA PM Feature Request Workflow v2 - TEMP [ 2031603 ]
            Confluence Escalation Bot (Inactive) made changes -
            Labels New: affects-server
            Hoang Dong (Inactive) made changes -
            Component/s Original: ↓ Obsolete -- VersionBoard (Classic) [ 12963 ]
            Martin (Inactive) made changes -
            Backlog Order (Obsolete) Original: 130040000000
            Workflow Original: GreenHopper Kanban Workflow v2 [ 302696 ] New: JIRA PM Feature Request Workflow v2 [ 738312 ]
            Issue Type Original: Story [ 16 ] New: Suggestion [ 10000 ]
            Priority Original: Major [ 3 ]
            Stuart Bargon [Atlassian] made changes -
            Status Original: Resolved [ 5 ] New: Closed [ 6 ]

              Unassigned Unassigned
              caefa62aac8f Dimitar Dimitrov
              Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

                Created:
                Updated:
                Resolved: