+1 Developers that solve the problem by fixing the issue should change the status to "Resolved" and the person who create the issue could change the status to "Closed" to verify.
- Henry On Fri, Mar 27, 2015 at 6:52 AM, Maximilian Michels <m...@apache.org> wrote: > Hmm. In my eyes, "Closed" is for one-time issues that are not likely to > occur again. "Resolved" is to mark the issue as resolved with possible > issues coming up in the course of usage or testing. I would say, "Closed" > is more from an end-user perspective, whereas "Resolved" marks the > developer's result of fixing the issue. > > On Fri, Mar 27, 2015 at 2:41 PM, Robert Metzger <rmetz...@apache.org> wrote: > >> @Vasia: I don't know. I use "Closed" for issues which are invalid or won't >> fix. >> Resolved for those that were implemented. >> >> On Wed, Mar 18, 2015 at 2:57 PM, Vasiliki Kalavri < >> vasilikikala...@gmail.com >> > wrote: >> >> > Thanks for this Robert! I updated the gelly-related closed issues. >> > BTW, what's the difference between closed and resolved? Any case where we >> > should use one over the other? >> > >> > -Vasia. >> > >> > On 18 March 2015 at 10:34, Robert Metzger <rmetz...@apache.org> wrote: >> > >> > > I would appreciate if everyone who is merging pull requests is properly >> > > setting the "fix version" in JIRA. >> > > >> > > So in most cases, the "fix version" is the next major release, >> currently >> > > 0.9. >> > > If we're not setting this, the issue will not appear in the changelog >> of >> > > the release. Also, I think that users may find JIRAs via Google, then >> > this >> > > information helps them to know when the feature will be available. >> > > Also, the fancy marketing metric (XY issues resolved) is suffering ;) >> > > >> > > >> > > By the way, does anybody know why we can not set the "fix version" for >> > > "Closed" JIRAs (instead of "Resolved")? In the "Resolved" case, we can >> > > still change that. >> > > >> > > >> > > On Thu, Oct 9, 2014 at 9:46 AM, Fabian Hueske <fhue...@apache.org> >> > wrote: >> > > >> > > > Yes, I think more discipline with JIRA issues would be definitely >> good >> > > and >> > > > ease the management of releases. >> > > > >> > > > I'd say the affected version should be initially the version (or >> > > versions) >> > > > where the issue was identified. >> > > > We than should check which other versions are affected and add these >> to >> > > the >> > > > JIRA. >> > > > Only the latest minor of each major release is relevant, e.g., 0.6.1 >> is >> > > > sufficient for all 0.6 releases. >> > > > >> > > > >> > > > 2014-10-08 21:50 GMT+02:00 Ufuk Celebi <u...@apache.org>: >> > > > >> > > > > Hey all, >> > > > > >> > > > > I was wondering what the policy is for marking issues with affected >> > and >> > > > > fix versions. I know that we suggested a couple of times (in >> > different >> > > > > email threads) that it would be desirable in order to get an >> > automatic >> > > > > changelog for releases etc. >> > > > > >> > > > > I think the fixed versions tag is clear: you mark the version for >> > which >> > > > it >> > > > > was fixed. >> > > > > >> > > > > Example: if I fix something in the current master (assuming current >> > > > master >> > > > > has not been branched off for 0.7-incubating) and I do a back port >> > for >> > > > > 0.6.1: then I mark the fix for the unreleased 0.7-incubating >> version >> > > and >> > > > > add the new release tag 0.6.2, right? >> > > > > >> > > > > What about the affected versions tag? Just the latest unreleased >> > > version, >> > > > > which is affected? Or all versions, where it should be fixed >> > (released >> > > > and >> > > > > unreleased) as well? >> > > > > >> > > > > – Ufuk >> > > > >> > > >> > >>
