[ https://issues.jboss.org/browse/JBIDE-22619?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen commented on JBIDE-22619: --------------------------------------------- I grok the reason about the idea for using sprint numbers in the jira fix version but it raises two questions for me: 1) historically we used to be pretty strict about not having "meaningless" jira versions - that the jira version meant something and it was the actual version used in the release/project metadata. does this proposal of having 4.4.1.S116 mean that the version in our pom's/osgi manifest etc. will actually state 4.4.1.S116 or still using "proper" version names/numbers ? 2) I assume if there in one sprint will be worked on two different versions, i.e. devstudio 9.1.x and devstudio 10.x the versions would be something like 9.1.1.S116 and 10.1.0.S116 ? ...my guess is that the answer to #1 is no and #2 is yes. And that just make me think ...why put the sprint number into the fixversion ? what is the point ? Is it because jiralint and our past approach been that we need to set the jira fixversion when working on an issue ? Could it then help if we make jiralint or something similar go and set the 'expected fix version' on issues that is in a sprint but have no fix version ? In that case dev's won't have to both set the sprint and fix version (unless there is something unexpected about it) -- This message was sent by Atlassian JIRA (v6.4.11#64026)