Hi, just upgrading now to Lucene 3.1 and go directly Final seems wrong to me as well. I agree that in this case we should do a CR2 first. If other deadlines are more important I think we have to defer the upgrade.

--Hardy On Mon, 04 Apr 2011 00:08:44 +0200, Sanne Grinovero <sanne(a)hibernate.org&gt; wrote: > Hello, > I'm sure you all have heard all the noise about the Lucene 3.1 > release, it has indeed some interesting changes [1]; it's almost > drop-in compatible with Lucene 3.0.x but providing some interesting > performance improvements and a huge amount of bugfixes. > Some of these fixes are memory leaks, index corruption, failing to > properly update index contents, returning stale IndexReaders.. a long > list of improvements that we would like to provide to our users as > well. > > In practice, I already did all the work: > https://github.com/Sanne/hibernate-search/commits/HSEARCH-705 > > Just one concern: we're currently in CR1 phase. > Shall we get this in, or postpone for 3.5 ? > > Some details: > > If someone was to try to use current Hibernate Search with Lucene 3.1: >  * Faceting won't work >  * RAMDirectory won't work > There are many more changes in the tests, but this is of no interest to > users. > > In the opposite case, if we upgrade and people wished to stay on > Lucene <3.1, it won't work: > we need to use some of the new APIs, especially TotalHitCountCollector > to count for matches is now a requirement when queryResultSize() is > used, but this class didn't exist in Lucene 3.0.x. > > The Infinispan Lucene Directory works fine with all versions of Lucene > 2.9.x, 3.0.x, 3.1.0, so this dependency is not going to block this. > > Opinions? if there's time for it, I'd propose a CR2 to get this update > in, would be nice to have HSEARCH-679 as well as Tom contributed a > test for it. > > Sanne