: 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.
FWIW: you can rename jira versions w/o losing information about what issues were associated with that version. (It's useful when you have release code names before you know what the version will actually be) but i don't really think we need to utilize that -- our release process makes it pretty self evident what the next release on any given branch will be : But... lacking that, maybe we really shouldn't use Next at all, and Agreed. I take most of the blame for introducing hte concept of next... http://mail-archives.apache.org/mod_mbox/lucene-dev/201005.mbox/%3calpine.deb.1.10.1005251052040.24...@radix.cryptio.net%3E ... but in my defense: no one said they thought it was a bad idea. The way things shook out after the 3x branch was created just evolved differently then i anticipated, resulting in no *need* to track this concept as an abstract version -- we have feature releases from both branches, and people use their judegment to decide which features hsould be backported, updating Jira as the go. We should definitely kill of "Next" ... i would suggest just removing it, and not bulk applying a new version (there is no requirement that issues have a version) : > 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? see the above link about the clean up i already did for the the 1.5 Fix (an easier view of hte full work log is via markmail: http://markmail.org/thread/7r4lfqddmjkqa3qy ). I made a concious decision at that time not to *remove* the 1.5 version from any issue, because those fixes/features do in fact exist on the 1.5 branch, which still exists, instead i focused on trying to ensure that all those issues had the *other* version info (ie: 3.1 or 4.0) tracked on them properly (as best i could based on CHANGES.txt) I still don't think it makes sense to *remove* the 1.5 version completely, but I went ahead updated Jira to change the status of "1.5" to "Archived" -- so it no longer shows up as an option when editing or searching ofr issues, but if you look at an issue that is mapped to 1.5 that metadata is still there. As far as the 27 issues that are "Closed|Resolve AND Next" ... it looks like most of them are issues that were either duplicates, or abandoned (in which case people rarely remember to "unset" the version info)... https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+SOLR+AND+resolution+in+%28Fixed%2C+%22Won%27t+Fix%22%2C+Duplicate%2C+Invalid%2C+Incomplete%2C+%22Cannot+Reproduce%22%2C+Later%2C+%22Not+A+Problem%22%29+AND+fixVersion+%3D+12315093 ...it looks like only 4 of them were genuinely "Fixed" and need their version info updated (which just means auditing hte commits to seee what branches and when) ... the rest can probably e ingored if we just delete "Next" as aversion. -Hoss
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
