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 https://issues.apache.org/jira/browse/
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
compatible.
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
