2011/4/4 Hardy Ferentschik <hardy(a)hibernate.org>:
just upgrading now to Lucene 3.1 and go directly Final seems wrong to me as
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.
of course, just I don't know how much the other deadlines are
important, vs how much we decided that to "cap" the effort on this
As almost all work was done already, I think we could give people a
week to try it out; the additional effort is just the release process.
On Mon, 04 Apr 2011 00:08:44 +0200, Sanne Grinovero <sanne(a)hibernate.org>
> I'm sure you all have heard all the noise about the Lucene 3.1
> release, it has indeed some interesting changes ; 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
> In practice, I already did all the work:
> 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
> 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.