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. 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. 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).
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.
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
