-
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.
Hello again.
Finally got around to upgrade to Jira 4.1 and then GreenHopper 5.0.1 and it works, and Nested Versions does indeed seem to solve what I was talking about, as for Upgrading GreenHopper, I guess it looses backwards compatibility at some point without me taking notice.
)...
Thats fair enough since I could just upgrade to Jira 4.1 so no biggie (except my limited time
Kind Regards
Jens Melgaard