lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grant Ingersoll <>
Subject Re: Lucene 2.2 soon?
Date Fri, 01 Jun 2007 17:09:37 GMT

On Jun 1, 2007, at 12:31 PM, Michael Busch wrote:

> Hi Team,
> since we released Lucene 2.1 in February there have been powerful  
> new features
> like "point-in-time searching" (LUCENE-710),  
> "Payloads" (LUCENE-755) and
> "API for pre-analyzed fields" (LUCENE-580), good performance  
> improvements like
> "multi-level skipping" (LUCENE-866),  "improved  
> buffering" (LUCENE-888) and
> "improved RAMDirectory performance" (LUCENE-431). In addition there  
> have been
> various other optimizations and bug fixes.
> Considering all these improvements I think it's time for a new  
> release,
> especially since many of you voted in February to have releases  
> more frequently.
> Another good thing is that since 2.1 we improved the build files  
> significantly.
> In 2.1 we had problems with failing contrib tests and wrong build  
> files in the
> binary package. Thanks to Hoss and Doron (and other contrib owners)  
> we fixed
> already most of those contrib problems, and I'm working on fixing  
> the binary
> build problem (LUCENE-894).
> I would volunteer to do the release work this time. In case of no  
> negative votes
> we could try to aim for a release date in about 2 weeks?
> If we can decided that we want to make a 2.2 release as I suggest I  
> will go
> ahead and create a staging area in my home directory like Yonik did  
> with 2.1.
> I really liked that approach. Next week I will then upload binary  
> and source
> packages built from the current trunk (after I committed 894). This  
> will *not*
> be a release candidate yet, but is supposed to give us the chance  
> to test the
> packages on different platforms to ensure that all build problems  
> we had in 2.1
> are solved.
> There are currently 9 issues in Jira targeted for 2.2:
> - LUCENE-510: "IndexOutput.writeString() should write length in  
> bytes",
>              Grant Ingersoll
>  Not much progress has been made here lately, so I think we should  
> move this
>  to 2.3?

Definitely, in fact, I am thinking of unassigning this one for now.

> - LUCENE-446: "search.function - (1) score based on field value,  
> (2) simple
>              score customizability", Doron Cohen
>  This looks ready to commit, Doron?
> - LUCENE-894: "Custom build.xml for binary distributions", Michael  
> Busch
>  I'm planning to commit this soon.
> - LUCENE-848: "Add supported for Wikipedia English as a corpus in  
> the benchmarker
>              stuff", Grant Ingersoll

Shouldn't block.

I have some pending changes on 
LUCENE-868, but don't let me hold you up.  I will try to get them in  
soon, so if they are in there, than great, otherwise continue on.  At  
any rate, they introduce new API things, but should be fully backward  

What say people about my suggestion of implementing a "code freeze"  
for 1-2 weeks prior to a release wherein we work on documentation and  
cleaning up JIRA?  Perhaps we _strive_ to have every committer (and  
others are welcome) to try to javadoc a set of files or to clean up  
some spot on the wiki or the main site?  Not saying this should be a  
show stopper, but it would really benefit all of us, I would think.   
Is this too much of a burden?  Anyone have other ideas that can help  
shore up our docs?  In theory, better docs lead to fewer questions  
which leads to more time to work on new features!

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message