If by changes you also mean deprecated features, then take a look at LUCENE-1614 - if you have your own Scorers/DISIs, you might want to implement the new methods, since the current ones are deprecated.
On Thu, May 28, 2009 at 1:23 AM, Yonik Seeley <yo...@lucidimagination.com>wrote: > We're aiming for a Solr release in the next few weeks (as usual, we're > 6 months behind when we wanted to make the release). > The catch is that Solr depends on Lucene 2.9, and there have been a > *lot* of changes. We're currently on r779312 (upgraded topday). > > I'll add a note to Solr to warn users from using new Lucene APIs in > plugins, and warn them to not upgrade the version of Lucene in Solr > themselves. Solr itself doesn't require API back compat from Lucene > of course... we'll figure out some way to get stuff to work. > > So concerns what does that leave? > - Index format stability... I believe since 2.4, the only change has > been commit metadata? Any guesses if the format for this remain > stable until 2.9 is released? > - stability in general (i.e. not crashing or producing corrupt indexes) > > Solr is using read-only readers, IndexReader.reopen(), > IndexReader.incRef(), etc. All deletes are via IndexWriter > We're also using the new Collector classes, new FieldComparator > classes including custom comparators. We're passing > docsScoredInOrder=true, and we also depend on docs coming back in > sorted order in some places. > > Solr is *not* using NRT features. > > Any thoughts or concerns? Any specific changes we should wait for? > > -Yonik > http://www.lucidimagination.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > >
