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

      I Searched a bit, and could not find something quite similar.
      This is actually a shared request between Jira / GreenHopper.

      The simplicity of how versions are managed currently is quite good, however ones you couple GreenHopper on top of it, we feel it lacks the ability to organizing versions as a "two level tree"...

      Problem is that a Version to be released may be produced over several planning cycles (Sprints) and as such the current way seems as a slight missfit.

      Weather you wan't to call it a Major/Minor version or something else, I don't know what would make most sense, but if versions was as:

      1.0.0.0

      • Sprint 1 / 1.1.0.0
      • Sprint 2 / 1.2.0.0
      • Sprint 3 / 1.3.0.0

      2.0.0.0

      • Sprint 4 / 2.1.0.0
      • Sprint 5 / 2.2.0.0
      • Sprint 6 / 2.3.0.0

      The sprint items could be used for planning the iterations, while the release notes ect. would be made from the versions.
      So in the above example, Sprint 1 to 3 would lead up to the release of version 1, while sprint 4-6 would lead up to version 2...

      It's a small improvement, but it would make it fit more into places where Release Cycles are not a direct map to planning cycles.

            [JSWSERVER-2189] Major / Minor Versions - Sub versions

              Unassigned Unassigned
              908a536c2a1d Jens
              Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

                Created:
                Updated:
                Resolved: