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.