Jira natively supports multiple versions on a ticket however the Greenhopper Planning Board does not. This is a real issue for us as greenhopper reuses the jira version field for sprints.

Essentially we maintain several versions of our products, and in one sprint we may be doing bugfixes/features on a couple different product versions. Thus nesting sprints under versions is not a good solution for us.

eg in one sprint we want to do feature development on version 2.0 and a couple bug fixes on version 1.1 of our product. The version 'Sprint x' cannot be a child of either of the two product versions. We are then forced to have sprint versions on the same level as product versions. This means in order to actually have the correct product version assigned to an issue, the developer has to manually edit the issue and add the version to it.
However, moving an issue between versions/sprints in the Greenhopper Planning board will result in resetting all previous versions manually set on an issue, so despite manually editing the ticket versions, the version can quickly and easily be lost.

A couple solutions we can think of are to:
1. We feel that the core of the issue comes from Greenhopper re-purposing Jira's version field. So the solution here is to have Greenhopper not to use the jira version field for sprints. This seems the most sensible option (for us), but will obviously require a fair change in greenhopper.
2. Allow CTRL + dragging in the planning board to ADD a version to an issue instead of replace the version. This would allow us to move all the issues we want to fix in version 2.0 to that version. Then when doing a sprint we would CTRL + drag the issue to the specific sprint. This would allow the issue to retain its original product version when adding it to a sprint on the same level as the product version. However, as this is an extra step, it could easily be forgotten, leaving us with the occasional bug with incorrect versioning.
3. Set up another custom field in Jira to store the actual product version in. Then the Jira Version field can be used entirely for greenhopper sprints (kindof backwards I know). Developers will have to manually edit issues and set the new 'Really fixed in Version' field. Doing it this way we also loose other Jira functionality such as the roadmap and release notes features...
4 other solutions welcome....?

We have a growing installation of Atlassian products company wide and this is the single biggest issue we have with being able to find a usable workflow.