-
Suggestion
-
Resolution: Resolved Locally
-
None
-
Standalone (v4.0#466)
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.