On 30 July 2010 16:21, Joe Bohn <[email protected]> wrote: > In general I agree with your proposal and Atlassian - "affects version" > documents the discovery and "fix version" documents the fix. > > However, you propose that an originator can set the "affects" and "fix" > versions to match when requesting a patch. We don't really provide patches.
I agree. I just wanted to keep the option open should someone want to provide a patch. We're talking about binary / built patches here which I think is unusual as I'd expect a user to manage these himself. > A fix could be included in a new minor release - but that should get a > unique version in the list. For example, the problem is discovered in 1.1 > and we don't want to wait for a 1.2 release - so we decide to produce a > 1.1.1 release to pull in this fix and perhaps many others. The "affects > version" should be 1.1 and the "fix version" should be 1.1.1. So I think when the issue is opened, the fix version should be left blank, and the user would request a new release (1.1.1) in this case and if creating a 1.1.1 release were agreed to then the "fix version" would be set to 1.1.1. > The only case > where the "affects" and "fix" versions should match is the case when a new > problem is discovered and fixed within the same version prior to its release > (basically a NOOP for a user that only picks up released artifacts). agreed > > Something else we might consider is only setting the "fix version" when the > issue is actually resolved. That might prevent some confusion because the > resolver would choose the fix version before resolving the JIRA rather than > allowing a previous entry which might be incorrect to stay in the JIRA > simply because the resolver either didn't notice it or was too lazy to > update it. I agree - that's a good practice. Only set the "fix version" when the issue is being marked as resolved. I had thought of an edge case: if the issue has two 'affects version' values then it may be subsequently fixed in both. e.g. if there were unreleased versions of 1.1.1 and 2.0. If the fix is different for those versions then there may be some time between it being fixed on one vs the other. In this case I think creating child issues is the way to go. > > Joe > > > On 7/30/10 10:28 AM, Jeremy Hughes wrote: >> >> Hi, I've noticed a few inconsistencies in the way some JIRA's have >> been opened w.r.t these fields. So I would like to get agreement on >> our understanding of these fields and how they should be used. >> >> The JIRA doc on Atlassian [1] describes the meanings for all the >> fields. In particular: >> >> Affects Version(s) (if applicable) — project version(s) for which the >> issue is (or was) manifesting. >> Fix Version(s) (if applicable) — project version(s) in which the issue >> was (or will be) fixed. >> >> My reading of this is: >> >> * When you create an issue, you should set the 'affects version/s' >> field to versions that you are using where you feel the issue is >> (ahem) an issue. That would be 0.1 and/or 0.2. Version 0.2 isn't >> released yet but that shouldn't matter. The 1.0 release and the >> 'Incubating' release shouldn't be there and I would like to remove >> those. >> >> * When you create an issue, you can also set the 'fix version/s'. You >> don't have to, you could just leave that to the assignee. If you, as >> the creator, set it to be the same as the 'affects version/s' field >> then you're effectively asking for a patch on that version. At the >> time the issue is resolved I would expect the 'fix version/s' to >> contain, at least, one version which hasn't yet been released, pending >> an imminent release. >> >> WDYT? >> >> [1] http://confluence.atlassian.com/pages/viewpage.action?pageId=185729613 >> >> Cheers, >> Jeremy >> > > > -- > Joe >
