Francois Orsini wrote: > Thanks for pointing that out Dan. So I take it that new features at this > point should be targeted at 10.2.0 _if_ we want them to be in the next > release that includes new features - right?
Easy answer, yes. However, it's not clear to me that we are treating the 'FixIn' field consistently, or even if it matters. :-) Does it mean 'it was fixed in 10.2.0.0', or 'I'm planning/want to fix in in 10.2.0.0', or both depending on if the bug is fixed or not. If it's the former then the value is only filled in when the bug/issue is fixed and the value should come from running sysinfo in the line where it is fixed. Thus if you fixed 528 today in the trunk then the fixin version would be 10.2.0.0. Of course the trouble comes, as with (almost) every other defect tracking system I've used, with the fact a bug can be fixed in multiple code lines, but the tool cannot represent that. E.g. for a bug, its real state may be 10.0.x.y - does not exist 10.1.x.y - exists and need to be fixed 10.2.0.0 - fixed Jira doesn't seem to support this, unless maybe sub-tasks are used. Dan.
