Bulk updating 240 Solr issues to set the Fix Version to "next" per the process outlined in this email...

http://mail-archives.apache.org/mod_mbox/lucene-dev/201005.mbox/%3Calpine.DEB.1.10.1005251052040.24672@radix.cryptio.net%3E

Selection criteria was "Unresolved" with a Fix Version of 1.5, 1.6, 3.1, or 4.0. email notifications were suppressed.

A unique token for finding these 240 issues in the future: hossversioncleanup20100527

It would be great to see explicit proximity operators using ordered SpanNearQuery. I believe we already have unordered span query support through "foo bar"~100

Perhaps this syntax could be extended to express ordered proximity, e.g. "foo bar"~>100

Bulk move 3.2 -> 3.3

3.4 -> 3.5

bulk fixing the version info for 4.0-ALPHA and 4.0 all affected issues have "hoss20120711-bulk-40-change" in comment

rmuir20120906-bulk-40-change

moving all 4.0 issues not touched in a month to 4.1

Jan Høydahl Jan: we implemented a new operator for Lucene / SOLR 3.4 that does exactly what you say, see: https://issues.apache.org/jira/browse/LUCENE-3758?focusedCommentId=13207710&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13207710

if you or anyone else needs a patch, just let me know.

Dmitry Kan, where is your code implemented? At Lucene query parser level?

[Jan Høydahl] at Lucene query parser level. New token FUZZY_SLOP_SHARP (name isn't probably the best sound, but can be changed) has been introduced in the QueryParser.jj and supportive code implemented. The syntax is same as that of ~ operator, i.e. "term1 term2 ... termn" #slope.

My impression was that Span queries and Payloads are kind of pase in Luceneland.... no?
If yes, should we Won't Fix this patchless 4 years old issue?

I wouldn't say payloads are, unless you are telling me there is a better solution, but we can handle that separately.

Bulk close resolved 4.4 issues