You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Michael Busch <bu...@gmail.com> on 2007/06/01 18:31:02 UTC
Lucene 2.2 soon?
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?
- 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-854: "Create merge policy that doesn't periodically inadvertently
optimize", Michael McCandless
Do you want to get this into 2.2, Mike?
- LUCENE-887: "Interruptible segment merges", Unassigned
I will move this to a later release.
The following 4 issue are about contrib packages and build warnings, I think
they'd be nice to get in but shouldn't hold up the release.
- LUCENE-875: "javadocs creation has too many warnings/errors", Doron Cohen
- LUCENE-876: "contrib/gdata has many javadoc warnings", Unassigned
- LUCENE-759: "Add n-gram tokenizers to contrib/analyzers", Otis Gospodnetic
- LUCENE-848: "Add supported for Wikipedia English as a corpus in the
benchmarker
stuff", Grant Ingersoll
Any others that should go in?
- Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Lucene 2.2 soon?
Posted by Michael Busch <bu...@gmail.com>.
Michael Busch wrote:
> There are currently 9 issues in Jira targeted for 2.2:
>
Good progress! Already down to 3 within a day!
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Lucene 2.2 soon?
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 6/4/07, Michael Busch <bu...@gmail.com> wrote:
> > PS. When doing 2.2, it would be nice if you could upload the release
> > artifacts also in the Maven repository. See the instructions in
> > http://wiki.apache.org/jakarta-lucene/ReleaseTodo. Lucene 2.1 not
> > being in the Maven repository is the main blocker for Jackrabbit not
> > to upgrade right away.
>
> We're already working on getting the upload into the Maven repository
> done right this time.
> (See https://issues.apache.org/jira/browse/LUCENE-622)
Nice, thanks a lot to everyone involved!
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Lucene 2.2 soon?
Posted by Michael Busch <bu...@gmail.com>.
Hi Jukka,
> Big +1 from me! We're doing a big 1.4 release of Jackrabbit in a few
> months and many of the improvements you listed would be very much
> welcome.
Cool!
>
> PS. When doing 2.2, it would be nice if you could upload the release
> artifacts also in the Maven repository. See the instructions in
> http://wiki.apache.org/jakarta-lucene/ReleaseTodo. Lucene 2.1 not
> being in the Maven repository is the main blocker for Jackrabbit not
> to upgrade right away.
We're already working on getting the upload into the Maven repository
done right this time.
(See https://issues.apache.org/jira/browse/LUCENE-622)
- Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Lucene 2.2 soon?
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 6/1/07, Michael Busch <bu...@gmail.com> wrote:
> 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.
Big +1 from me! We're doing a big 1.4 release of Jackrabbit in a few
months and many of the improvements you listed would be very much
welcome.
PS. When doing 2.2, it would be nice if you could upload the release
artifacts also in the Maven repository. See the instructions in
http://wiki.apache.org/jakarta-lucene/ReleaseTodo. Lucene 2.1 not
being in the Maven repository is the main blocker for Jackrabbit not
to upgrade right away.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Lucene 2.2 soon?
Posted by Doug Cutting <cu...@apache.org>.
Chris Hostetter wrote:
> : yet incorporate voting. In the past, we've not always voted on release
> : artifacts, but that's Apache policy. A release should not be made
> : unless its binary file has at least 3 +1 votes from PMC members. I
>
> Is that really a hard and fast policy? My reading of the voting policy
> docs is that only "Votes on Code Modification" have a strict "PMC
> members have the only binding votes" while other types of votes allow the
> definiton of 'binding' to be "community-specific" ... i was under the
> impression that in the past the lucene community has treated all committer
> votes for releases as binding.
>
> http://www.apache.org/foundation/voting.html
I think that page is unfortunately ambiguous on this point. But, from
discussions I've seen on board@ and members@, it is clear that many
senior members of the ASF think only PMC votes are binding for releases.
That's not to say that other votes have no value, but rather just that
the PMC has the final sign-off and responsibility for releases. In
theory, perhaps a PMC can delegate that responsibility to a project's
committers, but that'd be frowned on by many. So I think we should be
conservative and observe the 3+ PMC members rule.
Also note that anyone who votes on a release binary should download it,
test it, check it's signature, etc., and not just trust that it contains
what was agreed on.
Doug
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Lucene 2.2 soon?
Posted by Chris Hostetter <ho...@fucit.org>.
: yet incorporate voting. In the past, we've not always voted on release
: artifacts, but that's Apache policy. A release should not be made
: unless its binary file has at least 3 +1 votes from PMC members. I
Is that really a hard and fast policy? My reading of the voting policy
docs is that only "Votes on Code Modification" have a strict "PMC
members have the only binding votes" while other types of votes allow the
definiton of 'binding' to be "community-specific" ... i was under the
impression that in the past the lucene community has treated all committer
votes for releases as binding.
http://www.apache.org/foundation/voting.html
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Lucene 2.2 soon?
Posted by Doug Cutting <cu...@apache.org>.
Grant Ingersoll wrote:
> What say people about my suggestion of implementing a "code freeze" for
> 1-2 weeks prior to a release
The process we're using on Hadoop is to have a feature freeze at a
specified date. Trunk is branched at that point. Only blocker issues
are permitted to be applied to the branch. We then generally apply
patches for blockers first to trunk and then merge them to the branch
from trunk. Then, once there are no blockers, we can build a candidate
release to vote on. Note that new features can be added to trunk, but
they'll not be merged to the branch, so trunk development need not
stall. We use Jira's "Fix Version" to determine whether a patch is
intended for the branch or only for trunk.
I note that http://wiki.apache.org/jakarta-lucene/ReleaseTodo doesn't
yet incorporate voting. In the past, we've not always voted on release
artifacts, but that's Apache policy. A release should not be made
unless its binary file has at least 3 +1 votes from PMC members. I
recently added this to Hadoop's wiki
(http://wiki.apache.org/lucene-hadoop/HowToRelease).
> 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!
Probably, in addition to blockers, documentation patches should be
permitted after the feature freeze. And taking some time out to examine
the documentation is certainly a good idea.
Doug
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Lucene 2.2 soon?
Posted by Michael Busch <bu...@gmail.com>.
> And this isn't just for our users. There are a lot of significant
> changes being proposed (or already committed) to the merging/indexing
> process, and I know I, for one, would benefit from having a good,
> coherent, unbroken writeup of it in the javadocs after the issues
> have been worked out.
Yes, definetly useful.
> By doing this at release time, we can avoid the dreaded pain of
> constantly rewriting it as it is being developed.
Should we try to decide which issues shall go into 2.2 by Tuesday
(06/05)? And then we could aim for a release about 2 weeks later, let's
say on Monday, 6/18? I will then create a branch on Tuesday or Wednesday
as Doug suggested and we will have a feature freeze on that branch until
2.2 is ready. During those two weeks we should test the build and
packaging, commit bug fixes if neccessary and focus on the javadocs,
as you suggest, Grant.
> As an aside, there are a few open issues already related to the
> index package and the demo/getting started page.
I think you refer to LUCENE-765 and LUCENE-805, right? Let's try to
do the javadoc improvements in some coordinated way: Let's gather here
which javadocs we want to improve for 2.2 by Tuesday as well and open
Jira issues. Well and then we have to assign those issues to volunteers
(why do I have the feeling that this is the hardest part :-) ).
> I am more concerned w/ the Javadocs at this point than the website,
> mostly b/c I think the website is a major undertaking (not that I am
> discouraging working on it), at least the part about writing a good
> tutorial and getting started page, but maybe I am wrong. I know that
> writing the scoring.html page was a significant undertaking for me and
> doing a similar page for indexing/analysis will likely be the same.
Yes, that's what I meant: writing these docs will take some time and
should not hold up the release.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Lucene 2.2 soon?
Posted by Grant Ingersoll <gs...@apache.org>.
On Jun 1, 2007, at 2:54 PM, Michael Busch wrote:
>
> On the other hand I'm not sure why we would need a code freeze. I
> think
> it will take longer than just one or two weeks to improve the docs
> significantly. We should probably open some Jira issues for the
> different spots where we want to add documentation. That way we can
> track them separately and the different committers can assign those
> issues to them.
>
My thoughts are that by all of us agreeing to write docs, especially
javadocs, for 1-2 weeks as part of a code freeze (at whatever level
of commitment possible), we are far more likely to prioritize this
work and make real headway. The tendency is always to work on new
features, etc. so I figured if we just set aside small chunks of time
to bite off a small piece of the docs at a time we will get a lot
further in this realm than if we feel like we have to get it all
done. I just know the tendency of all developers is to avoid docs
and work on things that are more "interesting", so that is my
rationale for "docs week".
And this isn't just for our users. There are a lot of significant
changes being proposed (or already committed) to the merging/indexing
process, and I know I, for one, would benefit from having a good,
coherent, unbroken writeup of it in the javadocs after the issues
have been worked out. While I understand the gist of most of what is
being proposed via the emails, having it written down more formally
would benefit us all in a way that the email discussions can not. By
doing this at release time, we can avoid the dreaded pain of
constantly rewriting it as it is being developed.
As an aside, there are a few open issues already related to the index
package and the demo/getting started page.
> After 2.2 is released we can start working then on an improved
> website.
> I can tell you that I'm certainly motivated to improve our
> documentation
> because I think we can have the best piece of software ever here,
> but if
> we don't document and present if appropriately it is only half baked.
> Well, I don't mean that our docs are bad (especially compared to some
> other projects), but there's certainly room for improvements.
>
>
I am more concerned w/ the Javadocs at this point than the website,
mostly b/c I think the website is a major undertaking (not that I am
discouraging working on it), at least the part about writing a good
tutorial and getting started page, but maybe I am wrong. I know that
writing the scoring.html page was a significant undertaking for me
and doing a similar page for indexing/analysis will likely be the same.
Cheers,
Grant
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Lucene 2.2 soon?
Posted by Michael Busch <bu...@gmail.com>.
Grant Ingersoll wrote:
>
> 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!
>
Grant,
I really like your initiative to improve our documents! I also have a
couple of ideas about how to improve the website and the docs. I will
comment about this on your other thread on java-dev.
On the other hand I'm not sure why we would need a code freeze. I think
it will take longer than just one or two weeks to improve the docs
significantly. We should probably open some Jira issues for the
different spots where we want to add documentation. That way we can
track them separately and the different committers can assign those
issues to them.
After 2.2 is released we can start working then on an improved website.
I can tell you that I'm certainly motivated to improve our documentation
because I think we can have the best piece of software ever here, but if
we don't document and present if appropriately it is only half baked.
Well, I don't mean that our docs are bad (especially compared to some
other projects), but there's certainly room for improvements.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Lucene 2.2 soon?
Posted by Grant Ingersoll <gs...@apache.org>.
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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Lucene 2.2 soon?
Posted by Michael McCandless <lu...@mikemccandless.com>.
"Michael Busch" <bu...@gmail.com> wrote:
> - LUCENE-854: "Create merge policy that doesn't periodically inadvertently
> optimize", Michael McCandless
> Do you want to get this into 2.2, Mike?
No, I don't think this should block a 2.2 release. I will clear the
Fix version on it.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Lucene 2.2 soon?
Posted by Michael Busch <bu...@gmail.com>.
> Michael, I updated LUCENE-446, including these
> warnings. Is 2.2 still open for adding this?
>
>
Hi Doron,
yes it is. I just sent a note to java-dev with a possible schedule for the
2.2 release in which I suggest to have a feature freeze from Wednesday
on. So features can still be committed until end of tomorrow (Tuesday).
- Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Lucene 2.2 soon?
Posted by Doron Cohen <DO...@il.ibm.com>.
Michael Busch wrote on 01/06/2007 23:31:11:
> With 9 votes this is the most popular issue in Jira.
> I understand your concerns about the API. Maybe we
> should commit this with comments in the javadocs saying
> that this feature is in beta state and that the APIs
> might still be subject to change?
Michael, I updated LUCENE-446, including these
warnings. Is 2.2 still open for adding this?
Thanks,
Doron
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Lucene 2.2 soon?
Posted by Chris Hostetter <ho...@fucit.org>.
: So I will add this now, and 831 would wait I guess for the next release.
831 should definitely not hold up 2.2 ... i wrote it and even i'm not
certain that it's the right way to go.
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Lucene 2.2 soon?
Posted by Doron Cohen <DO...@il.ibm.com>.
Chris Hostetter wrote on 03/06/2007 20:44:09:
> : The part I am not sure of in this regard are my changes
> : to FieldCache and FieldcacheImpl, while LUCENE-831 is
> : ongoing too. (though btw 831 doesn't apply cleanly on
> : current trunk). (It is my plan to get into LUCENE-831
> : but I haven't got to it yet.)
>
> 1) i updated 831 to work on the trunk
> 2) the spirt of 831 is to change the underlying impl but still be
> backwards compatible with the FieldCache API ... i skimmed the FieldCache
> API changes in the latest patch on 446, and they seem to just be adding
> new get methods (getShort, and getBytes) on the existing underlying impl
> .. that should be easily supported by the stuff in 831 (and easy to
> convert/migrate the same way i did the getInt/getLong/getString methods)
Indeed, this is the only change.
So I will add this now, and 831 would wait I guess for the next release.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Lucene 2.2 soon?
Posted by Chris Hostetter <ho...@fucit.org>.
: The part I am not sure of in this regard are my changes
: to FieldCache and FieldcacheImpl, while LUCENE-831 is
: ongoing too. (though btw 831 doesn't apply cleanly on
: current trunk). (It is my plan to get into LUCENE-831
: but I haven't got to it yet.)
1) i updated 831 to work on the trunk
2) the spirt of 831 is to change the underlying impl but still be
backwards compatible with the FieldCache API ... i skimmed the FieldCache
API changes in the latest patch on 446, and they seem to just be adding
new get methods (getShort, and getBytes) on the existing underlying impl
.. that should be easily supported by the stuff in 831 (and easy to
convert/migrate the same way i did the getInt/getLong/getString methods)
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Lucene 2.2 soon?
Posted by Doron Cohen <DO...@il.ibm.com>.
Regarding LUCENE-446 (function queries):
Michael Busch wrote on 01/06/2007 23:31:11:
> > This is new API, so I was kinda waiting for some feedback on it.
> > Another passible issue is that it expands FieldCache and
> > FieldcacheImpl - while LUCENE-831 "Complete overhaul of
> > FieldCache API/Implementation" is also changing it.
> > So I think this can wait for the next release.
> With 9 votes this is the most popular issue in Jira. I
> understand your concerns about the API. Maybe we should
> commit this with comments in the javadocs saying
> that this feature is in beta state and that the APIs
> might still be subject to change?
I am okay with this - stating that the API is not final
yet works well here since o.a.l.search.function is an
entirely new package.
The part I am not sure of in this regard are my changes
to FieldCache and FieldcacheImpl, while LUCENE-831 is
ongoing too. (though btw 831 doesn't apply cleanly on
current trunk). (It is my plan to get into LUCENE-831
but I haven't got to it yet.)
I will clean it a bit and go on with committing this
unless there are objections.
Doron
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Lucene 2.2 soon?
Posted by Michael Busch <bu...@gmail.com>.
Doron Cohen wrote:
>
> This is new API, so I was kinda waiting for some feedback on it.
> Another passible issue is that it expands FieldCache and
> FieldcacheImpl - while LUCENE-831 "Complete overhaul of
> FieldCache API/Implementation" is also changing it.
> So I think this can wait for the next release.
>
>
With 9 votes this is the most popular issue in Jira. I understand your
concerns about the
API. Maybe we should commit this with comments in the javadocs saying
that this feature
is in beta state and that the APIs might still be subject to change?
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Lucene 2.2 soon?
Posted by Doron Cohen <DO...@il.ibm.com>.
Michael Busch wrote on 01/06/2007 09:31:02:
> - LUCENE-446: "search.function - (1) score based on
> field value, (2) simple score customizability", Doron Cohen
> This looks ready to commit, Doron?
This is new API, so I was kinda waiting for some feedback on it.
Another passible issue is that it expands FieldCache and
FieldcacheImpl - while LUCENE-831 "Complete overhaul of
FieldCache API/Implementation" is also changing it.
So I think this can wait for the next release.
> - LUCENE-875: "javadocs creation has too many warnings/errors",
This is actually done - we eventually decided not to fail the run
because of javadoc warnings or errors. I will resolve it.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org