Kathey Marsden wrote: > Recently there have been several discussions about the meaning of many > of the Jira fields. [snip] > Affects Version - The earliest release where the issue is known to > exist as shown by sysinfo. > RESOLVE: What should this mean for non-bug issues? > > Fix Version for Closed Issues - > The earliest release where the fix has been made and forward ported to > all higher rev maintenance branches and the trunk. > The assumption is that you can move to the latest of a higher rev > maintenance branch and get the fix. For example if the current trunk > version is 10.2 and the fix is in 10.0 , but not in 10.1, the issue > should just be resolved with Fix Version 10.2 and a comment added for > the special backport. Of course fixes that have not been fixed in the > trunk should not be marked resolved.
So Jira is one of the few bug tracking systems I've worked with that allows multiple affects and fix-in versions, but this proposal seems to be insisting on a single value in each of the "affects" and "fix" version fields. I don't think this is a good approach, how would these situations be handled? 1) Bug can be seen in 10.1.1.2, 10.1.3.1 but not 10.1.2.4? 2) Bug has been fixed in 10.2 and someone back ported it to 10.0.1.3 but it still exists in the 10.1 line? 3) Users see a bug and and useful information to the affects field to say "Yes - I also saw this bug in this other release". I think you are saying 2) would be handled with a "special comment", I see that as unworkable, they can't be searched on, it's not obvious to others that they should be looking for such comments. The fix version field is the obvious place to store this information. Why not use the power of the tool? > (Note: The current practice of marking multiple fix versions creates > problems with release notes and doesn't make sense because you should > really then mark fixin 10.3, 10.4 etc...) Not sure I understand what you are trying to say here. If the problem of handling multiple versions is in generating the release notes, then that's the process that should be fixed. [snip] > If this looks like a good start at definitions I can put it on the Wiki > and then we can refine. This is a great start. Thanks, Dan.
