> > my point is just that when bulk editing these things, > we should just un-set instead of rolling forward >
+1. Before 3.1 I reviewed the list of issues that were not updated since Jan 1st 2009, and closed most of them (those that looked like they're either solved or not of interest anymore). Some issues that were updated post that date were not commented on, or had a patch update or something, but their update date attribute was affected by version changes and the like. So if we unset the version flag going forward, it will be clearer (and easier) to determine which issues are really old and can be closed. : personally, when i set these versions on issues, i set versions > : 3.x+4.0 usually to indicate that I think its applicable to both the > : stable branch and trunk (versus 4.0-only indicating its not the kind > : of thing that should be backported). > > that makes sense too -- personally I think we should be stricter about it > ... we should only mark something as fix for 3.3 if we think (at the time > we are reviewing/updating the issue) that we really shouldn't release 3.3 > w/o this fix/feature. > Actually both approaches make sense to me :). I personally set the version flag of every issue I report, but I will try to avoid that, and set the flag for issues I'm sure I'll have time to work on for the next release, or are important enough for the next release. Otherwise, important issues will fall between the cracks and forgotten (until one day my giant old-issues-sweeping broom will get rid of them :)). Shai On Fri, May 20, 2011 at 10:27 PM, Chris Hostetter <[email protected]>wrote: > : personally, when i set these versions on issues, i set versions > : 3.x+4.0 usually to indicate that I think its applicable to both the > : stable branch and trunk (versus 4.0-only indicating its not the kind > : of thing that should be backported). > > that makes sense too -- personally I think we should be stricter about it > ... we should only mark something as fix for 3.3 if we think (at the time > we are reviewing/updating the issue) that we really shouldn't release 3.3 > w/o this fix/feature. > > obviously things change ... one day we think something should definitely > be in a release, two weeks later we might decide that it's too much work, > or too complex to try and shoehorn in, and we conciously change it the > version. > > I'm not suggesting that anyone change their current practice of how/when > they choose what version to mark on a jira issue when they are reviewing a > particular issue -- my point is just that when bulk editing these things, > we should just un-set instead of rolling forward: If some issues have > fallen by the way-side to the point that we are bulk editing them out of > blocking the current release, that's a pretty good indicator that they > aren't a priority for the next release unless someone steps forward and > deliberately says they should be. > > > -Hoss > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
