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.