Hi Greg, I agree with you that the "fix version" field for unresolved issues is probably used by issue creators to express their wish for fast resolution. I also saw some cases where issues were reopened.
I agree with your suggestion to clear the "fix version" field once 1.0.0 has been released. On Mon, Feb 22, 2016 at 4:43 PM, Greg Hogan <c...@greghogan.com> wrote: > Hi, > > With 1.0.0 imminent there are 112 tickets with a "fix version" of 1.0.0, > the earliest from 2014. From the ticket logs it looks like we typically > bump the fix version once the target release has passed. Would it be better > to wait to assign a fix version until achieving some combination of > severity, acceptance, and imminence? > > For example, a new feature might go unscheduled until a pull request is > available, whereas a blocker is by definition intended for the next > release. > > A corollary would be to unschedule all open / in progress / reopened > tickets once their "fix version" has been released. This would present a > clean slate for the next round of commits. > > Greg >
