lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler" <>
Subject Release 3.0 soon
Date Wed, 11 Nov 2009 00:24:30 GMT
Hi other developers,


I am still on heavy committing, but I think we have fixed almost everyting
for Lucene 3.0. The public API uses generics, enum, varargs,...; all
deprecations scheduled for 3.0 are removed. The following issues are still





LUCENE-1558 <> 

Make IndexReader/Searcher ctors readOnly=true by default

Michael McCandless

LUCENE-1370 <> 

Patch to make ShingleFilter output a unigram if no ngrams can be generated

Karl Wettin

LUCENE-1948 <> 

Deprecating InstantiatedIndexWriter

Karl Wettin

LUCENE-1973 <> 

Remove deprecated query components

Uwe Schindler

LUCENE-2052 <> 

Scan method signatures and add varargs where possible

Uwe Schindler

LUCENE-1845 <> 

if the build fails to download JARs for contrib/db, just skip its tests

Simon Willnauer

LUCENE-1698 <> 

Change backwards-compatibility policy

Michael Busch

LUCENE-2024 <> 

"ant dist" no longer generates md5's for the top-level artifacts


LUCENE-2047 <> 

IndexWriter should immediately resolve deleted docs to docID in
near-real-time mode

Michael McCandless

LUCENE-2050 <> 

Improve contrib/benchmark for testing near-real-time search performance

Michael McCandless

LUCENE-2051 <> 

Contrib Analyzer Setters should be deprecated and replace with ctor


LUCENE-1081 <> 

Remove the "Experimental" warnings from search.function package


LUCENE-1909 <> 


Grant Ingersoll


The red one is finished, I just wait for comments or something against. The
yellow one needs to be discussed. The other ones are simple fixes that
should be resolved soon.


I left out the Java-5-Issue, because it is a neverending story (you can
always find unneeded casts, generics warnings,.), but the import thing is,
that the public API is generified. Everything else can be easily fixed after
release of 3.0.


LUCENE-1558 has one problem: The methods were deprecated in 2.9, but
reappear with different behaviour in 3.0, which is bad. Maybe we should add
them in 3.1 again, so users coming from 2.9 will not see strange behaviour.
Else it should be marked red in the changes backwards section, that the
methods were undeprecated, because they are no longer the same methods like
before and now have different behaviour. So something like: "was deprecated
in 2.9 because no support for the previous behaviour anymore. Readded in 3.0
as "new methods".


I want to start the release process during the weekend (my first tests as
release manager), so I can throw out RC1 on next Monday or so.





Uwe Schindler

H.-H.-Meier-Allee 63, D-28213 Bremen



View raw message