On 9/8/06, Kathey Marsden <[EMAIL PROTECTED]> wrote:
My reasoning for not marking multiple versions is that the fix ends up getting rolled up into the Jira release notes for the next release. DERBY-176 for example is marked fixed in 10.2.1.0 and 10.3.0.0 (Thanks for the fix BTW!) It is in the Jira 10.2.1.0 release notes It is in the 10.3.0.0 release notes but it will not be in the 10.4.0.0 release notes presumably the fix implicit because it is fixed in 10.3, but of course it was really fixed in a previous release. But why should it be in the 10.3 release notes then? My thought was that it should just be marked fixed 10.2.1.0 and then not show up in the 10.3 release notes at all.
There's two problems that I see. One is that releases are not really sequential on a time scale or even guaranteed to happen. A fix that was made in 10.2 and merged to 10.1.4 will almost certainly be released in 10.2 before 10.1.4. Wouldn't it make sense for 10.2 to document the behavior, especially if it needs a proper release note? In that case, it should really show up on JIRA queries for 10.2 issues with the release notes check box. And what if 10.1.4 is never released? If it is only documented as being fixed in 10.1.4 it will never be seen in a set of released release notes. The other problem that I could see is that the fix for the issue in 10.2 may not be the same fix that goes into 10.1 for various reasons, because 10.2 may have changed significantly in the area of the fix and so the fix may be implemented differenty, and it might require different release note in 10.1 because the fixes are different. Having it properly documented in both seems like a good idea. That's why I tend to view Fix In in JIRA as datapoints that document where - what branches - activity around the issue occurred, not when, and why I think it would be advantageous in some circumstances to be documented in more than one release. andrew
