# Lucene 6.2 version in final 5.0?

**URL:** <https://discuss.elastic.co/t/lucene-6-2-version-in-final-5-0/55181>\
**Category:** Elasticsearch\
**Created:** [July 11, 2016, 10:59am UTC](https://discuss.elastic.co/t/lucene-6-2-version-in-final-5-0/55181 "2016-07-11T10:59:32Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![byronvoorbach](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/byronvoorbach/32/8283_2.png) [@byronvoorbach](https://discuss.elastic.co/u/byronvoorbach)\
**Post date:** [July 11, 2016, 10:59am UTC](https://discuss.elastic.co/t/lucene-6-2-version-in-final-5-0/55181/1 "2016-07-11T10:59:33Z")

</div>

Hi all,

Will Lucene 6.2 be part of the 5.0 release??  
I'm mentioning this because I just noticed that [https://issues.apache.org/jira/browse/LUCENE-2605](https://issues.apache.org/jira/browse/LUCENE-2605) has been resolved a couple of days ago. Would really love to see this coming to Elasticsearch asap! 😃

Thanks,

---

<div class="post-metadata">

**Author:** ![polyfractal](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/polyfractal/32/48162_2.png) [@polyfractal](https://discuss.elastic.co/u/polyfractal)\
**Post date:** [July 11, 2016, 5:43pm UTC](https://discuss.elastic.co/t/lucene-6-2-version-in-final-5-0/55181/2 "2016-07-11T17:43:19Z")

</div>

Maybe, maybe not. Really hard to say at this point, unfortunately. GA is still a ways off, so we're not sure if Lucene will be bumped in the meantime.

I agree that it would be nice to get that fix in though! 🙂

---

<div class="post-metadata">

**Author:** ![byronvoorbach](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/byronvoorbach/32/8283_2.png) [@byronvoorbach](https://discuss.elastic.co/u/byronvoorbach)\
**Post date:** [September 8, 2016, 11:33am UTC](https://discuss.elastic.co/t/lucene-6-2-version-in-final-5-0/55181/3 "2016-09-08T11:33:53Z")

</div>

Hey @polyfractal!

It's been 2 months since my last post on this topic and I was wondering if you maybe have an update on this? 😃

I need the fix for a project I'm working on.  
If it's not going to be a part of 5.0.0 / 2.7 , do you have any suggestions on how to get this fix in at least locally (if possible)?

Thanks in advance!

---

<div class="post-metadata">

**Author:** ![polyfractal](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/polyfractal/32/48162_2.png) [@polyfractal](https://discuss.elastic.co/u/polyfractal)\
**Post date:** [September 8, 2016, 1:14pm UTC](https://discuss.elastic.co/t/lucene-6-2-version-in-final-5-0/55181/4 "2016-09-08T13:14:35Z")

</div>

You're in luck! Lucene 6.2 was merged into master about two weeks ago, meaning 5.0 will be cut with (at least) Lucene 6.2: [https://github.com/elastic/elasticsearch/pull/20147](https://github.com/elastic/elasticsearch/pull/20147)

🙂

---

<div class="post-metadata">

**Author:** ![byronvoorbach](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/byronvoorbach/32/8283_2.png) [@byronvoorbach](https://discuss.elastic.co/u/byronvoorbach)\
**Post date:** [September 8, 2016, 1:31pm UTC](https://discuss.elastic.co/t/lucene-6-2-version-in-final-5-0/55181/5 "2016-09-08T13:31:28Z")

</div>

Ohh great!

Any chance it's going to end up in a 2.X version?, or should we to move to 5.X?

Thanks for the quick reply! 😃

---

<div class="post-metadata">

**Author:** ![polyfractal](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/polyfractal/32/48162_2.png) [@polyfractal](https://discuss.elastic.co/u/polyfractal)\
**Post date:** [September 8, 2016, 2:13pm UTC](https://discuss.elastic.co/t/lucene-6-2-version-in-final-5-0/55181/6 "2016-09-08T14:13:33Z")

</div>

I can almost guarantee 2.x won't be upgraded to Lucene 6. We only upgrade Lucene major versions when the ES major version also bumps.

Lucene guarantees one major version of backwards compatibility. So that means 2.x clusters (which are on Lucene 5) can read Lucene 4 segments. If we introduced Lucene 6 to 2.x, there may be old segments that suddenly become unreadable despite ES not introducing a major version bump.

So we only bump Lucene majors when ES majors bump, to coalesce the bwc breaks to just major versions 🙂

---

<div class="post-metadata">

**Author:** ![byronvoorbach](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/byronvoorbach/32/8283_2.png) [@byronvoorbach](https://discuss.elastic.co/u/byronvoorbach)\
**Post date:** [September 8, 2016, 2:19pm UTC](https://discuss.elastic.co/t/lucene-6-2-version-in-final-5-0/55181/7 "2016-09-08T14:19:33Z")

</div>

Hmmm that makes sense..

Since we're in a state right now that we would like to move to production with our application soon, waiting for 5.0.0 and getting it through the entire ecosystem once it's out is gonna take too long for us. 😰

In order to get this fix in, do you think we should wait? Or fork the project and bump Lucene ourselves? Any thoughts?? 🙂

Thanks again,

---

<div class="post-metadata">

**Author:** ![polyfractal](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/polyfractal/32/48162_2.png) [@polyfractal](https://discuss.elastic.co/u/polyfractal)\
**Post date:** [September 8, 2016, 3:00pm UTC](https://discuss.elastic.co/t/lucene-6-2-version-in-final-5-0/55181/8 "2016-09-08T15:00:25Z")

</div>

Yeah, it's tricky spot to be in. Beta1 should be out soonish (I forget the exact date, but soon). Then RC after that, or potentially a second beta.

TBH, I would be suuuuper cautious forking and bumping Lucene yourself. Even ignoring the work involved in upgrading from 5.5 to 6.2, you could easily find yourself in a situation where there's an incompatibility between your fork and official ES. Which would put you in a bad spot if/when you want to upgrade, you may have to reindex everything, etc because the incompatibility is not upgradeable.

At that point, you'd be "safer" running off alpha or beta.

What kind of problems are you running into? I think it'd be much easier to work around the query\_string quirks. E.g. identify the problematic fields and exclude them from querying via query\_string, and instead add extra, specific queries against those fields in a big `bool`. Or use a `multi_match`, etc.

---

<div class="post-metadata">

**Author:** ![jprante](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jprante/32/44941_2.png) [@jprante](https://discuss.elastic.co/u/jprante)\
**Post date:** [September 8, 2016, 3:13pm UTC](https://discuss.elastic.co/t/lucene-6-2-version-in-final-5-0/55181/9 "2016-09-08T15:13:37Z")

</div>

@byronvoorbach I don't think you need the whole machinery of Lucene 6+ just in order to fix a relatively small issue about whitespace tokenization in `query_string`. You should know that Lucene's query string syntax is broken inherently for a long time. Just look at Elasticsearch `simple_query_string`, which is a sane query parser to get rid of the quirks of `query_string`. You can write an ES plugin with a modified `query_string` parser in Elasticsearch to achieve your goal, if `simple_query_string` does not fit your purpose.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [July 5, 2017, 10:21pm UTC](https://discuss.elastic.co/t/lucene-6-2-version-in-final-5-0/55181/10 "2017-07-05T22:21:47Z")

</div>


