Nice, done: depending on Lucene 2.9.1 right now.
Sanne
2010/1/11 Emmanuel Bernard :
> Right, go forward and temporarily break COMPRESS.
> Option B (ie use CompressionTools) seems like a better option than getting
> rid of it altogether.
> I think we should offer a pluggable compression method bu
Right, go forward and temporarily break COMPRESS.
Option B (ie use CompressionTools) seems like a better option than getting rid
of it altogether.
I think we should offer a pluggable compression method but I would not mind it
being global and thus not require change to the enum.
On 11 janv. 2010
On Sun, 10 Jan 2010 20:39:28 -0300, Sanne Grinovero
wrote:
> Hello again,
> it got better I've a simple patch ready to migrate to 2.9.1, all tests
> green;
> it was easier than I initially thought to fix the new DocIdSet
> shall I apply it?
+1 from my side.
> We can then think about the com
Hello again,
it got better I've a simple patch ready to migrate to 2.9.1, all tests green;
it was easier than I initially thought to fix the new DocIdSet
shall I apply it?
We can then think about the compression issue and after that move 3.0.x
I've moved HSEARCH-424 "Update to Lucene 3.0" from bet
Hello all,
I've been thinking about the strategy to upgrade to Lucene 3;
Ignoring new features at the moment, the main issues in migration:
1- Store.COMPRESS not supported anymore
2- Some Analyzers and the QueryParser require an additional
constructor parameter
3- DocIdSet interface (used in filte
