Uwe, how about you look at that, I will look at contrib leftovers. In my opinion the type safety of generics is more important than some varargs syntactic sugar...
On Tue, Nov 10, 2009 at 7:36 PM, Uwe Schindler <u...@thetaphi.de> wrote: > The only Java 5 thing in core is LUCENE-2052, for which I find no Eclipse > plugin… So „grep“ with heavy regex is needed and maybe an UnexpectedSuccess > on finding some more varargs. > > The current tests are not converted to generics, but that is really > unimportant because it is not public API. > > > > Robert: I think the contrib things are the only leftovers. > > ----- > Uwe Schindler > H.-H.-Meier-Allee 63, D-28213 Bremen > http://www.thetaphi.de > eMail: u...@thetaphi.de > ------------------------------ > > *From:* Robert Muir [mailto:rcm...@gmail.com] > *Sent:* Wednesday, November 11, 2009 1:32 AM > > *To:* java-dev@lucene.apache.org > *Subject:* Re: Release 3.0 soon > > > > Hi Uwe, > > I think we all appreciate the heavy committing you have done for 3.0! > > With regards to the java 5 issue, I think all that is left is contrib? > Is there any more work in core to be done for java 5 in 3.0? > > On Tue, Nov 10, 2009 at 7:24 PM, Uwe Schindler <u...@thetaphi.de> wrote: > > 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 > open: > > > > *Key* > > *Summary* > > *Assignee* > > *LUCENE-1558 <https://issues.apache.org/jira/browse/LUCENE-1558>* > > Make IndexReader/Searcher ctors readOnly=true by default > > Michael McCandless > > *LUCENE-1370 <https://issues.apache.org/jira/browse/LUCENE-1370>* > > Patch to make ShingleFilter output a unigram if no ngrams can be generated > > Karl Wettin > > *LUCENE-1948 <https://issues.apache.org/jira/browse/LUCENE-1948>* > > Deprecating InstantiatedIndexWriter > > Karl Wettin > > *LUCENE-1973 <https://issues.apache.org/jira/browse/LUCENE-1973>* > > Remove deprecated query components > > Uwe Schindler > > *LUCENE-2052 <https://issues.apache.org/jira/browse/LUCENE-2052>* > > Scan method signatures and add varargs where possible > > Uwe Schindler > > *LUCENE-1845 <https://issues.apache.org/jira/browse/LUCENE-1845>* > > if the build fails to download JARs for contrib/db, just skip its tests > > Simon Willnauer > > *LUCENE-1698 <https://issues.apache.org/jira/browse/LUCENE-1698>* > > Change backwards-compatibility policy > > Michael Busch > > *LUCENE-2024 <https://issues.apache.org/jira/browse/LUCENE-2024>* > > "ant dist" no longer generates md5's for the top-level artifacts > > Unassigned > > *LUCENE-2047 <https://issues.apache.org/jira/browse/LUCENE-2047>* > > IndexWriter should immediately resolve deleted docs to docID in > near-real-time mode > > Michael McCandless > > *LUCENE-2050 <https://issues.apache.org/jira/browse/LUCENE-2050>* > > Improve contrib/benchmark for testing near-real-time search performance > > Michael McCandless > > *LUCENE-2051 <https://issues.apache.org/jira/browse/LUCENE-2051>* > > Contrib Analyzer Setters should be deprecated and replace with ctor > arguments > > Unassigned > > *LUCENE-1081 <https://issues.apache.org/jira/browse/LUCENE-1081>* > > Remove the "Experimental" warnings from search.function package > > Unassigned > > *LUCENE-1909 <https://issues.apache.org/jira/browse/LUCENE-1909>* > > Make IndexReader.DEFAULT_TERMS_INDEX_DIVISOR public > > 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 > > > > ----- > > Uwe Schindler > > H.-H.-Meier-Allee 63, D-28213 Bremen > > http://www.thetaphi.de > > eMail: u...@thetaphi.de > > > > > > > -- > Robert Muir > rcm...@gmail.com > -- Robert Muir rcm...@gmail.com
