OK, so if we want to fix Fieldable/Field/AbstractField and
InputDoc/OutputDoc (and any other API-changers), we need to do
it for 2.9 not 3.0.
So then the question boils down to whether we should block 2.9 on
these big changes?
My feeling is if nobody steps up (has the itch time) to work on
Grant Ingersoll wrote:
I just don't see how we will ever get to 3.0 if we continue this
path. People don't seem interested in much beyond new features and
bug fixes, so if we're going to do this 2.9 to 3.0 thing, I think we
need to go for it a bit more wholeheartedly and say that 2.9
On Dec 19, 2008, at 6:08 AM, Michael McCandless wrote:
Grant Ingersoll wrote:
I just don't see how we will ever get to 3.0 if we continue this
path. People don't seem interested in much beyond new features and
bug fixes, so if we're going to do this 2.9 to 3.0 thing, I think
we need
Michael McCandless wrote:
Are you saying we can deprecate these classes in 2.9, and all methods
whose signature involves one of these classes, without offering the
new classes?
No. Folks should be able to recompile w/o deprecation warnings against
2.9, then upgrade to 3.0. Features should
Jason Rutherglen wrote:
Broadly speaking, what areas are we looking to create new APIs for in
2.9? How dramatic are we looking to go?
That's not really the question. We shouldn't rush to get big API
changes in. Rather we should continue to cautiously evolve the API.
Periodically, when
Any more thoughts on this...?
This seems like a big confusion (whether we can deprecate X without
introducing new API Y, in 2.9 -- I don't see how), at least for me,
holding up 2.9.
Mike
Michael McCandless wrote:
Grant Ingersoll wrote:
On Dec 14, 2008, at 6:54 AM, Michael
Broadly speaking, what areas are we looking to create new APIs for in 2.9?
How dramatic are we looking to go? I figured making Lucene more modular
should wait until 3.0, after a fair amount of brainstorming. If 2.9 is
supposed to contain 3.0 APIs then there should probably be a 2.5 release.
As
I was confused (still learning the ropes) but are others? Our back
compatibility states that when we deprecate we will offer the transition
API - it doesn't appear hard lined, as it says the strategy is, but it
seems like its probably something we should stick with. From what I
read, the only
I just don't see how we will ever get to 3.0 if we continue this
path. People don't seem interested in much beyond new features and
bug fixes, so if we're going to do this 2.9 to 3.0 thing, I think we
need to go for it a bit more wholeheartedly and say that 2.9 truly is
not going to have
: 2.9, 3.0 and deprecation]
Yes, typo.. long day yesterday
Uwe Schindler wrote:
I've only read through the jdoc of tier so far, but I'm guessing it's
doing a dictionary search and splitting the the index readers position
based on the result being less than or greater than upper / lower
Yes, typo.. long day yesterday
Uwe Schindler wrote:
I've only read through the jdoc of tier so far, but I'm guessing it's
doing a dictionary search and splitting the the index readers position
based on the result being less than or greater than upper / lower values.
Which may be
LUCENE-1483, LUCENE-831, LUCENE-1314
Helps for realtime.
5. Is there anything we would need to deprecate now if we were to take
advantage of 1.5 concurrent packages?
The contrib ParallelMultiSearcher
On Sun, Dec 14, 2008 at 3:54 AM, Michael McCandless
luc...@mikemccandless.com wrote:
About LocalLucene, it would benefit (be faster) by integrating with
TrieRangeQuery for the bounding box filter.
On Sun, Dec 14, 2008 at 3:54 AM, Michael McCandless
luc...@mikemccandless.com wrote:
I'd also personally like to see 2.9 released sooner rather than later,
maybe earliesh next year?
?revision=66view=markup
This gives you a bounding box lookup of about 3 - 4 ms on a 3 million
doc index.
Thanks
Patrick
Sean Timm wrote:
Subject:
Re: 2.9, 3.0 and deprecation
From:
"Jason Rutherglen" jason.rutherg...
/ http://www.pangaea.de/
E-mail: uschind...@pangaea.de
_
From: patrick o'leary [mailto:polear...@aol.com]
Sent: Monday, December 15, 2008 9:14 PM
To: java-dev@lucene.apache.org
Subject: Re: [Fwd: Re: 2.9, 3.0 and deprecation]
Hey Jason
o.a.l.s.trie looks interesting and has a lot
Subject: Re: [Fwd: Re: 2.9, 3.0 and deprecation]
Hey Jason
o.a.l.s.trie looks interesting and has a lot of potential, locallucene 1.5+
release moved to a Cartesian tier system away from
the boundary box filter a while though.
A TierRange or RangeFilter as the one I used in v1.0 was a little
359 Bremen
Tel.: +49 421 218 65595
Fax: +49 421 218 65505
http://www.pangaea.de/
E-mail: uschind...@pangaea.de
From:
patrick o'leary [mailto:polear...@aol.com]
Sent: Monday, December
15, 2008
9:14 PM
To: java-dev@lucene.apache.org
Subject: Re: [Fwd: Re:
2.9, 3.0
and d
I've only read through the jdoc of tier so far, but I'm guessing it's
doing a dictionary search and splitting the the index readers position
based on the result being less than or greater than upper / lower values.
Which may be faster than a TermDocs seek, and certainly
worth while
I'd also personally like to see 2.9 released sooner rather than later,
maybe earliesh next year?
I don't think we should hold up 2.9 for some of the big items below
(eg Fieldable/AbstractField/Field cleanup), especially if they have
not even been started yet.
One question: I'm assuming after
On Dec 14, 2008, at 6:54 AM, Michael McCandless wrote:
I'd also personally like to see 2.9 released sooner rather than later,
maybe earliesh next year?
I don't think we should hold up 2.9 for some of the big items below
(eg Fieldable/AbstractField/Field cleanup), especially if they have
not
Grant Ingersoll wrote:
On Dec 14, 2008, at 6:54 AM, Michael McCandless wrote:
I'd also personally like to see 2.9 released sooner rather than
later,
maybe earliesh next year?
I don't think we should hold up 2.9 for some of the big items below
(eg Fieldable/AbstractField/Field cleanup),
So, we got 2.4 out of the way (thanks, Mike!) and we have agreed,
pending build releases, that we are ready to move onto 2.9 and then
3.0. Our strategy for this is generally to mark in 2.9 all things
that we want to remove as deprecated, such that one needs to address
the deprecations in
22 matches
Mail list logo
