On 2011-06-04 19:33, Henri Yandell wrote:
> On Fri, Jun 3, 2011 at 7:43 PM, Phil Steitz <phil.ste...@gmail.com> wrote:
>> On 6/3/11 7:27 PM, Henri Yandell wrote:
>>> On Fri, Jun 3, 2011 at 2:09 PM, Simone Tripodi <simonetrip...@apache.org> 
>>> wrote:
>>>>> I think that is also best practice - resolve when fixed in SVN,
>>>>> close when fix version is released.
>>>>>
>>>> I couldn't agree more!!! +1!
>>> I just close directly. The resolve then close is a workflow waiting
>>> for a reason :)
>>
>> The reason is that until a release has been cut including the fix,
>> it is still a problem faced by users.  Just fixing in svn should not
>> close the issue.
> 
> Not a good enough reason imo. If 'Resolved' was called 'Committed' and
> 'Closed' was 'Released', then maybe. As it is we'll have a workflow
> that is meaningless to anyone but the committers; and they can already
> look at whether the fix version has been released or not.
> 
> If Atlassian hadn't made the mistake of a 2 stage resolution as their
> default; we wouldn't be looking for a solution. As they did everyone
> (not just here, it's a JIRA anti-pattern) tries to apply a workflow to
> the Resolve/Close step.

The way I try to use this over in Maven land, is like this.

When I have committed a fix for an issue and have deployed a new
SNAPSHOT of it to a public repo, I "Resolve" the issue.

In an ideal world the user then tries the new SNAPSHOT to verify that it
solves his/her problem, and the user then "Close" the issue. Or he/she
asks the developer to do it for them by stating that the issue has been
fixed. If the user is no longer around I just close the issue *before*
the release is made.

The "Status" field doesn't tell us whether the fix has been released or
not. That is what the "Fix version/s" field is for.

> Hen
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 
> 


-- 
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to