I don't think "Next" is necessarily dangerous; if used then "3.2", shouldn't exist until it's time to release. Having both is dangerous. But sure, I'm in favor of removing "Next". A committer would have to adjudicate all issues and substitute either 3.2 or 4.0. Speaking of which, I think simply assigning a fix-version for "3.2" implies that it will be for any future release (including 4.0) and so I don't see there's a point in assigning both of these fix-versions. There are rare exceptions to this and I am aware of course that our dual-development branches implies having to make two commits.
RE v1.5, fortunately, most of the issues are already assigned a suitable fix-version other than 1.5 so those can be ignored. Once the few remainder are addressed, v1.5 can be deleted. RE Next, Any issue with a resolution status of "Fixed" should be re-assigned a suitable fix-version if it doesn't have any. There are very few of these two worry about. Those without a resolution status should probably just be assigned to 3.2 -- so yes I agree that's what we should do. Then "Next" can be deleted. ~ David Smiley Michael McCandless-2 wrote: > > On Fri, Apr 29, 2011 at 12:12 AM, David Smiley (@MITRE.org) > <[email protected]> wrote: > >> (Comments on SOLR-2191 between Mark & I were starting to get off-topic >> with >> respect to the issue so I am continuing the conversation here) >> >> A lot of JIRA issues seem to fall off the radar, IMO. I'm talking about >> issues that have patches and are basically ready to go. There are >> multiple >> ways to address this but at the moment I am going to just bring up one. >> Looking at the versions in JIRA one can assign an issue to >> https://issues.apache.org/jira/browse/SOLR#selectedTab=com.atlassian.jira.plugin.system.project%3Aversions-panel >> I see the version named "Next", with this description: "Placeholder for >> commiters to track issues that are not ready to commit, but seem close >> enough to being ready to warrant focus before the next feature release". >> This version and what it implies is a common pattern in use of JIRA that >> I >> too use for projects I manage for my employer. It appears that for the >> 3.1 >> release, nobody looked through the issues assigned to "Next", and >> consequently, some issues like SOLR-2191 were forgotten despite being >> ready >> to go. Looking through the wiki I see information on how to do a release >> http://wiki.apache.org/solr/HowToRelease and release suggestions but no >> information on what to do in advance of a release. I also don't see any >> administrative tasks on managing the "Next" version in JIRA. So I think >> either the "Next" version should be used effectively, or if that isn't >> going >> to happen then delete this version. > > I agree Next is dangerous! > > It'd be nice if Jira could auto-magically treat Next as whatever > release really is "next". EG, say we all agree 3.2 is our next > release, then ideally Jira would treat all Next issues as if they were > marked with 3.2. > > But... lacking that, maybe we really shouldn't use Next at all, and > just use 3.2? Having to step through these issues and move them to > the next release on releasing is also healthy, ie, it's good that we > see/review them, think about why we didn't get it done on the current > release, etc. > >> On a related note, I don't know what to make of the "1.5" version, nor >> what >> to make of issues marked as Closed for "Next". Some house cleaning is in >> order. > > We should clean these up. Should we just roll them over to 3.2? > > Mike > > http://blog.mikemccandless.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > ----- Author: https://www.packtpub.com/solr-1-4-enterprise-search-server/book-- View this message in context: http://lucene.472066.n3.nabble.com/Re-jira-issues-falling-off-the-radar-Next-JIRA-version-tp2886427p2886427.html Sent from the Lucene - Java Developer mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
