[hibernate-dev] Lucene 3.1 : we're ready as well, but should have have it in 3.4?

[Hardy Ferentschik]

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 at hibernate.org>  
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