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