On 10/30/06, Mike Matrigali <[EMAIL PROTECTED]> wrote:
I think it is best to leave fix in version blank. For the last release rick and kathy were using fix in to indicate what release it "would be nice" to get a particular fix in. I think this use becomes very confusing, especially once a patch goes in. Does it now mean that the fix is actually in that version or not? Even more confusing if there are multiple fix in set. I do think it is nice to generate reports with candidate bugs for a special release, but I don't have an alternate suggestion. We are definitely overloading a field here, it would be nice if there were an "actually fixed in field" and a "target fix in field".
I think that if a bug is Resolved, then its Fix In should reflect the versions where code changes were made that resulted in the issue being fixed. If the bug is Open/Reopened then I take the Fix In field to mean that is the target release(s) for which the issue should be fixed. A problem arises when the issue has been fixed in one release (e.g. whatever the trunk version is currently) but it remains open because the fix should be ported to another release (some close-to-release branch). It can be hard to tell in that case what is really going on in that case, but I've been relying on scanning the Subversion changes view in JIRA to determine if the fix has been applied to all the versions in the Fix In list if there are multiple versions there. my 2 cents, andrew
