title: Sprint versions vs Release versions in Jira and Greenhopper
body: <p>When using Greenhopper with Jira, it is clear that Greenhopper is using the "fixed in version" field in the Jira issues to represent which scrum sprint the issue is being worked on. This in itself is a bit hackish, because an issue can conceivably be worked on in multiple sprints, and because the relationship between an issue and a sprint is precisely that it has been <em>worked on</em> during the sprint, with the recognition that you might not complete the task within the planned time.</p>
  
  <p>But okay, it might be a hack one can live with, at least if there is nothing else that tries to use the "fixed in version" field for something else.</p>
  
  <p>But I am finding that there are other concerns that also build on the "fixed in version" field. Specifically, one should be able to see which issues are <em>planned</em> to be addressed in which <em>release versions</em> (real-life versions), and to use this information as a means of verification/QA.</p>
  
  <p>How are other Greenhopper users combining these two uses of the "fixed in versions" field? Are you setting the sprint versions as sub-versions of the release versions? Are you using some custom field for the release versions? I am finding this to be difficult because the scrum team is working on multiple components, independently versioned. Also, there may be bugfix releases and feature development on the same component, happening on the same sprint.</p>
  
  <p>To summarise, I find it unavoidable that the team will be working on "Some Product 3.4.0" (a feature release), "Some Product 3.3.1" (a bugfix release), and "Other Product 1.2" within the same sprint. It would not be possible to mark this sprint as a subversion of each of these three versions (across two different components). And making three different sprints in Greenhopper, would really dilute the value of Greenhopper.</p>
  
  <p>Are other Greenhopper users in this same situation? How have you dealt with it?</p>