Mailing-List: contact aries-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: aries-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of joebohn@gmail.com designates
 209.85.213.47 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=StbLEyLLnxq6zMYs9c5kckMDJXil4HdCUXvIAZ4bX/rQTI9/b51AQipT7p5vsgS74u
         o2I/GIx7e5MdYdqYtN20SodKCDlyZM18XcmGg6gqGzMBhL1qPtofH+oR9qWeIndZceIF
         f9msHlS3BcSDlRLTtUc1oYQ6k6L3MTRUKoeUw=
Message-ID: <4C52EDF6.4070501@gmail.com>
Date: Fri, 30 Jul 2010 11:21:26 -0400
From: Joe Bohn <joebohn@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US;
 rv:1.9.1.11) Gecko/20100711 Lightning/1.0b1 Thunderbird/3.0.6
MIME-Version: 1.0
To: aries-dev@incubator.apache.org
Subject: Re: How to use the JIRA 'Affects version/s' and 'Fix Version/s'
 fields
References: <AANLkTinoRRpwuXG=1vkUs27TqCOxQfSz4GRkgYVes5nk@mail.gmail.com>
In-Reply-To: <AANLkTinoRRpwuXG=1vkUs27TqCOxQfSz4GRkgYVes5nk@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

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