You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Grant Ingersoll <gs...@apache.org> on 2008/10/21 23:02:32 UTC
2.9, 3.0 and deprecation
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 order to move up to 3.0. In this case, we are
also moving to Java 1.5 as the base.
I thought I would kick off the discussion with some areas of interest:
1. Splitting Index time Document from Search time Document per Hoss'
ideas on a variety of threads in the past. Something to the gist of
having an InputDocument and an OutputDocument (and maybe an abstract
Document for shared features) such that people wouldn't be confused
about calling index time things on Document during search and vice
versa.
2. Java 1.5 (who knows, maybe by 2020, we can be on 1.6!). This
means we can use Generics, or as I like to call them "Specifics" since
the specifically say what is in the collection as opposed to the
current collections where you can put any generic object in them. :-)
3. Michael B. is proposing a new Token API (but it's back compat.)
4. Mike M. is doing some new flex indexing stuff (but it's back compat.)
5. Is there anything we would need to deprecate now if we were to take
advantage of 1.5 concurrent packages?
6. Local Lucene is of interest to a lot of people. Does it require
anything special in terms of deprecation? (me thinks not)
7. Same goes for the real time stuff, PFOR implementation, column-
stride fields, etc.
8. I think we should do a review of what's open in JIRA again and see
if we can come to conclusions on any of them, such that going into
3.0, JIRA is relatively clean.
9. For 3.0, what cruft from 1.x can we remove from the file format,
since 3.x need not read 1.x format _if_ doing so is advantageous to us?
10. There has been some talk about changing how StandardTokenizer
labels some tokens. What can we do in there to deprecate?
11. Fieldable. Ah, Fieldable. I believe this is going to become an
abstract base class, or go away.
I'm sure I'm missing lots of other things that we've talked about. I
figured I'd start the discussion, and then maybe we can put it on the
wiki and then break it out to JIRA, or even just go from here to
individual JIRA issues.
Personally, I'd like to push towards 2.9 in a fairly short time frame
(in Lucene terms) of something like 3-4 mos, but that's just me.
Thoughts? Please correct me if I misunderstood the process at all.
Forever Herding Cats,
Grant
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: 2.9, 3.0 and deprecation
Posted by Doug Cutting <cu...@apache.org>.
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 large numbers of things have been deprecated and
they're hampering further development, we can have a major release in
order to discard them. 3.0 will not be the last release.
Doug
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: 2.9, 3.0 and deprecation
Posted by Jason Rutherglen <ja...@gmail.com>.
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 far as a modular API, it seems like doing something like what Token does
with Attributes could also be used for (in place of?) TermEnum, TermDocs,
TermPositions which are simply iterators over a specific data type. This
seems related to Flexible Indexing.
Would 2.9 have the modular replacement for IndexReader?
It will be helpful to agree on a list of features that is prioritized.
On Thu, Dec 18, 2008 at 2:13 PM, Michael McCandless <
lucene@mikemccandless.com> wrote:
>
> 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 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 even been started yet.
>>>>
>>>
>>> Well, if they are going to be changed, they need to at least be
>>> deprecated, right?
>>>
>>
>> But we can't deprecate old APIs until we've added new APIs, in a release?
>>
>> 2.9 has turned into a feature release, when that has never been the plan.
>>>
>>
>> Good point, though is that a problem? I suppose we could do a 2.5 release
>> before 2.9, if so.
>>
>> One question: I'm assuming after 2.9 is out, we would fairly quickly
>>>> follow that up with a 3.0 that has more or less just removed
>>>> deprecations?
>>>> (Vs doing alot of dev putting new features into 3.0 as well).
>>>>
>>>> More comments below:
>>>>
>>>> Grant Ingersoll wrote:
>>>>
>>>> 1. Splitting Index time Document from Search time Document per Hoss'
>>>>> ideas on a variety of threads in the past. Something to the gist of having
>>>>> an InputDocument and an OutputDocument (and maybe an abstract Document for
>>>>> shared features) such that people wouldn't be confused about calling index
>>>>> time things on Document during search and vice versa.
>>>>>
>>>>
>>>> Maybe don't hold 2.9 for this one? (There's been lots of discussion,
>>>> and also recently interesting discussion on adding type safety to Document
>>>> under LUCENE-831, but nothing yet concrete).
>>>>
>>>
>>> As I said above, I don't see how we can. Either it gets deprecated now
>>> (note, we don't have to have the new version now) or it doesn't get changed
>>> for 3.x is my understanding of the process.
>>>
>>
>> OK I guess I don't understand the "note, we don't have to have the new
>> version now" -- was this done in the past? Ie in 1.9 we deprecated APIs not
>> knowing what the future migration path would be? And then in 2.0
>> development the replacement was completed & available & deprecated APIs were
>> then removed?
>>
>> Mike
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
Re: 2.9, 3.0 and deprecation
Posted by Doug Cutting <cu...@apache.org>.
Michael McCandless wrote:
> My feeling is if nobody steps up (has the "itch" & time) to work on
> these big changes (which haven't really proceeded beyond
> brainstormings on how we might fix them) soonish, we should not block
> 2.9 for them...
+1
Doug
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: 2.9, 3.0 and deprecation
Posted by Michael McCandless <lu...@mikemccandless.com>.
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
these big changes (which haven't really proceeded beyond
brainstormings on how we might fix them) soonish, we should not block
2.9 for them...
Mike
Doug Cutting wrote:
> 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 not be deprecated
> until they have a replacement, unless they're being removed forever.
>
> Doug
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: 2.9, 3.0 and deprecation
Posted by Doug Cutting <cu...@apache.org>.
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 not be deprecated until they
have a replacement, unless they're being removed forever.
Doug
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: 2.9, 3.0 and deprecation
Posted by Grant Ingersoll <gs...@apache.org>.
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 to go for it a bit more wholeheartedly and say that 2.9
>> truly is not going to have any new features and is solely going to
>> be about deprecation. Thus, we should be able to do 2.5 and then
>> soon thereafter do 2.9, otherwise the urge to "fix and extend" will
>> always be there.
>
> Why can't 2.9 have new features as well as deprecation? Looking back
> in CHANGES.txt, 1.9 seems to have done that.
Hmm, OK. Didn't notice that, I just thought it was. Sounds good, then.
>
>
>> I personally think it's possible to deprecate w/o having to say
>> what the new thing is going to look like, in some cases. A major
>> release should be an opportunity to clean up and improve, but we
>> shouldn't have to decide all of it immediately. We know what we
>> don't like, but that doesn't mean we necessarily have what we do
>> like decided on. I think it's too much of a burden.
>
>
> Maybe a specific example can move this discussion forward:
>
> We know we want to eventually refactor Fieldable/AbstractField/Field;
> there's been lots of good discussion here but no concrete effort yet
> to make it happen. It's a very big change.
>
> 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?
Yes. I think Document is another case. Hoss has made the case for an
InputDoc and an OutputDoc.
>
>
> But if we did that... wouldn't we then be forced into creating the new
> classes for 3.0? Is that that approach you're picturing?
>
> I don't think that's realistic, because if we haven't started dev for
> such a big change in 2.9, what makes us think in the 3.0 timeframe we
> can finish it? We'd be digging ourselves into a hole.
I don't know that is so much a concern about finishing it, but
something just might not even be possible in 2.9. For instance,
totally hypothetical: we deprecate something that we know we are
going to replace w/ a 1.5 feature.
>
>
> I guess my feeling is: if we do decide to block 2.9/3.0 release until
> Fieldable/AbstractField/Field is fixed, I'd rather do it all in 2.9
> (release the new APIs) than do it in 2 steps to avoid digging
> ourselves into a hole.
Which is the bigger hole, deciding it in 2.9 and publishing it and
therefore binding it for all of 3.x or just indicating we are going to
deprecate in 2.9?
FWIW, I also think we could choose to "un-deprecate" if we don't come
up w/ a better solution.
This isn't a big deal to me, I'm just trying to give us some
flexibility. I think sometimes we are so rigid about back
compatibility that it is hindering us. To me, a major release gives
us some wiggle room. Do I think we throw back compat out the window?
Of course not. Do I think it gives us some room to be less strict
about it? Yes.
I've said it before many times, and I think others have as well, given
the length of our release cycles (usually 6 months or more), I think
we give people more than enough time to react to changes. In this day
and age of intelligent refactoring tools and iterative development, I
don't think it is as great a burden. That being said, I'm not
advocating for unrestricted change at any point. I'd just like us not
to be so shackled by it at every turn. Seems to me, a move to a major
release is just one of those turns.
-Grant
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: 2.9, 3.0 and deprecation
Posted by Michael McCandless <lu...@mikemccandless.com>.
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 truly
> is not going to have any new features and is solely going to be
> about deprecation. Thus, we should be able to do 2.5 and then soon
> thereafter do 2.9, otherwise the urge to "fix and extend" will
> always be there.
Why can't 2.9 have new features as well as deprecation? Looking back
in CHANGES.txt, 1.9 seems to have done that.
> I personally think it's possible to deprecate w/o having to say what
> the new thing is going to look like, in some cases. A major release
> should be an opportunity to clean up and improve, but we shouldn't
> have to decide all of it immediately. We know what we don't like,
> but that doesn't mean we necessarily have what we do like decided
> on. I think it's too much of a burden.
Maybe a specific example can move this discussion forward:
We know we want to eventually refactor Fieldable/AbstractField/Field;
there's been lots of good discussion here but no concrete effort yet
to make it happen. It's a very big change.
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?
But if we did that... wouldn't we then be forced into creating the new
classes for 3.0? Is that that approach you're picturing?
I don't think that's realistic, because if we haven't started dev for
such a big change in 2.9, what makes us think in the 3.0 timeframe we
can finish it? We'd be digging ourselves into a hole.
I guess my feeling is: if we do decide to block 2.9/3.0 release until
Fieldable/AbstractField/Field is fixed, I'd rather do it all in 2.9
(release the new APIs) than do it in 2 steps to avoid digging
ourselves into a hole.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: 2.9, 3.0 and deprecation
Posted by Grant Ingersoll <gs...@apache.org>.
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 any new features and is solely going to be about
deprecation. Thus, we should be able to do 2.5 and then soon
thereafter do 2.9, otherwise the urge to "fix and extend" will always
be there.
I personally think it's possible to deprecate w/o having to say what
the new thing is going to look like, in some cases. A major release
should be an opportunity to clean up and improve, but we shouldn't
have to decide all of it immediately. We know what we don't like, but
that doesn't mean we necessarily have what we do like decided on. I
think it's too much of a burden.
-Grant
On Dec 18, 2008, at 8:54 PM, Mark Miller wrote:
> 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 difference with 3.0 is that
> we can drop deprecated stuff (and 1.x file formats).
>
> In that case, 3.0 offers us nothing special right? A chance to drop
> some cruft and little more?
>
> I'm all for a 2.5 if we want to get our ducks in a row for 2.9.
>
> +1 on starting a drive towards a release soon - if 2.9/3.0 is going
> to hold that up, lets just put it off and do a 2.5.
>
> - Mark
>
>
>
> Michael McCandless wrote:
>>
>> 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 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 even been started yet.
>>>>
>>>> Well, if they are going to be changed, they need to at least be
>>>> deprecated, right?
>>>
>>> But we can't deprecate old APIs until we've added new APIs, in a
>>> release?
>>>
>>>> 2.9 has turned into a feature release, when that has never been
>>>> the plan.
>>>
>>> Good point, though is that a problem? I suppose we could do a 2.5
>>> release before 2.9, if so.
>>>
>>>>> One question: I'm assuming after 2.9 is out, we would fairly
>>>>> quickly
>>>>> follow that up with a 3.0 that has more or less just removed
>>>>> deprecations?
>>>>> (Vs doing alot of dev putting new features into 3.0 as well).
>>>>>
>>>>> More comments below:
>>>>>
>>>>> Grant Ingersoll wrote:
>>>>>
>>>>>> 1. Splitting Index time Document from Search time Document per
>>>>>> Hoss' ideas on a variety of threads in the past. Something to
>>>>>> the gist of having an InputDocument and an OutputDocument (and
>>>>>> maybe an abstract Document for shared features) such that
>>>>>> people wouldn't be confused about calling index time things on
>>>>>> Document during search and vice versa.
>>>>>
>>>>> Maybe don't hold 2.9 for this one? (There's been lots of
>>>>> discussion, and also recently interesting discussion on adding
>>>>> type safety to Document under LUCENE-831, but nothing yet
>>>>> concrete).
>>>>
>>>> As I said above, I don't see how we can. Either it gets
>>>> deprecated now (note, we don't have to have the new version now)
>>>> or it doesn't get changed for 3.x is my understanding of the
>>>> process.
>>>
>>> OK I guess I don't understand the "note, we don't have to have the
>>> new version now" -- was this done in the past? Ie in 1.9 we
>>> deprecated APIs not knowing what the future migration path would
>>> be? And then in 2.0 development the replacement was completed &
>>> available & deprecated APIs were then removed?
>>>
>>> Mike
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
--------------------------
Grant Ingersoll
Lucene Helpful Hints:
http://wiki.apache.org/lucene-java/BasicsOfPerformance
http://wiki.apache.org/lucene-java/LuceneFAQ
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: 2.9, 3.0 and deprecation
Posted by Mark Miller <ma...@gmail.com>.
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 difference with 3.0 is that we can drop deprecated stuff
(and 1.x file formats).
In that case, 3.0 offers us nothing special right? A chance to drop some
cruft and little more?
I'm all for a 2.5 if we want to get our ducks in a row for 2.9.
+1 on starting a drive towards a release soon - if 2.9/3.0 is going to
hold that up, lets just put it off and do a 2.5.
- Mark
Michael McCandless wrote:
>
> 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 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 even been started yet.
>>>
>>> Well, if they are going to be changed, they need to at least be
>>> deprecated, right?
>>
>> But we can't deprecate old APIs until we've added new APIs, in a
>> release?
>>
>>> 2.9 has turned into a feature release, when that has never been the
>>> plan.
>>
>> Good point, though is that a problem? I suppose we could do a 2.5
>> release before 2.9, if so.
>>
>>>> One question: I'm assuming after 2.9 is out, we would fairly quickly
>>>> follow that up with a 3.0 that has more or less just removed
>>>> deprecations?
>>>> (Vs doing alot of dev putting new features into 3.0 as well).
>>>>
>>>> More comments below:
>>>>
>>>> Grant Ingersoll wrote:
>>>>
>>>>> 1. Splitting Index time Document from Search time Document per
>>>>> Hoss' ideas on a variety of threads in the past. Something to the
>>>>> gist of having an InputDocument and an OutputDocument (and maybe
>>>>> an abstract Document for shared features) such that people
>>>>> wouldn't be confused about calling index time things on Document
>>>>> during search and vice versa.
>>>>
>>>> Maybe don't hold 2.9 for this one? (There's been lots of
>>>> discussion, and also recently interesting discussion on adding type
>>>> safety to Document under LUCENE-831, but nothing yet concrete).
>>>
>>> As I said above, I don't see how we can. Either it gets deprecated
>>> now (note, we don't have to have the new version now) or it doesn't
>>> get changed for 3.x is my understanding of the process.
>>
>> OK I guess I don't understand the "note, we don't have to have the
>> new version now" -- was this done in the past? Ie in 1.9 we
>> deprecated APIs not knowing what the future migration path would be?
>> And then in 2.0 development the replacement was completed & available
>> & deprecated APIs were then removed?
>>
>> Mike
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: 2.9, 3.0 and deprecation
Posted by Michael McCandless <lu...@mikemccandless.com>.
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 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 even been started yet.
>>
>> Well, if they are going to be changed, they need to at least be
>> deprecated, right?
>
> But we can't deprecate old APIs until we've added new APIs, in a
> release?
>
>> 2.9 has turned into a feature release, when that has never been the
>> plan.
>
> Good point, though is that a problem? I suppose we could do a 2.5
> release before 2.9, if so.
>
>>> One question: I'm assuming after 2.9 is out, we would fairly quickly
>>> follow that up with a 3.0 that has more or less just removed
>>> deprecations?
>>> (Vs doing alot of dev putting new features into 3.0 as well).
>>>
>>> More comments below:
>>>
>>> Grant Ingersoll wrote:
>>>
>>>> 1. Splitting Index time Document from Search time Document per
>>>> Hoss' ideas on a variety of threads in the past. Something to
>>>> the gist of having an InputDocument and an OutputDocument (and
>>>> maybe an abstract Document for shared features) such that people
>>>> wouldn't be confused about calling index time things on Document
>>>> during search and vice versa.
>>>
>>> Maybe don't hold 2.9 for this one? (There's been lots of
>>> discussion, and also recently interesting discussion on adding
>>> type safety to Document under LUCENE-831, but nothing yet concrete).
>>
>> As I said above, I don't see how we can. Either it gets deprecated
>> now (note, we don't have to have the new version now) or it doesn't
>> get changed for 3.x is my understanding of the process.
>
> OK I guess I don't understand the "note, we don't have to have the
> new version now" -- was this done in the past? Ie in 1.9 we
> deprecated APIs not knowing what the future migration path would
> be? And then in 2.0 development the replacement was completed &
> available & deprecated APIs were then removed?
>
> Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: 2.9, 3.0 and deprecation
Posted by Michael McCandless <lu...@mikemccandless.com>.
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), especially if they have
>> not even been started yet.
>
> Well, if they are going to be changed, they need to at least be
> deprecated, right?
But we can't deprecate old APIs until we've added new APIs, in a
release?
> 2.9 has turned into a feature release, when that has never been the
> plan.
Good point, though is that a problem? I suppose we could do a 2.5
release before 2.9, if so.
>> One question: I'm assuming after 2.9 is out, we would fairly quickly
>> follow that up with a 3.0 that has more or less just removed
>> deprecations?
>> (Vs doing alot of dev putting new features into 3.0 as well).
>>
>> More comments below:
>>
>> Grant Ingersoll wrote:
>>
>>> 1. Splitting Index time Document from Search time Document per
>>> Hoss' ideas on a variety of threads in the past. Something to the
>>> gist of having an InputDocument and an OutputDocument (and maybe
>>> an abstract Document for shared features) such that people
>>> wouldn't be confused about calling index time things on Document
>>> during search and vice versa.
>>
>> Maybe don't hold 2.9 for this one? (There's been lots of
>> discussion, and also recently interesting discussion on adding type
>> safety to Document under LUCENE-831, but nothing yet concrete).
>
> As I said above, I don't see how we can. Either it gets deprecated
> now (note, we don't have to have the new version now) or it doesn't
> get changed for 3.x is my understanding of the process.
OK I guess I don't understand the "note, we don't have to have the new
version now" -- was this done in the past? Ie in 1.9 we deprecated
APIs not knowing what the future migration path would be? And then in
2.0 development the replacement was completed & available & deprecated
APIs were then removed?
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: 2.9, 3.0 and deprecation
Posted by Grant Ingersoll <gs...@apache.org>.
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 even been started yet.
Well, if they are going to be changed, they need to at least be
deprecated, right? 2.9 has turned into a feature release, when that
has never been the plan.
>
>
> One question: I'm assuming after 2.9 is out, we would fairly quickly
> follow that up with a 3.0 that has more or less just removed
> deprecations?
> (Vs doing alot of dev putting new features into 3.0 as well).
>
> More comments below:
>
> Grant Ingersoll wrote:
>
>> 1. Splitting Index time Document from Search time Document per
>> Hoss' ideas on a variety of threads in the past. Something to the
>> gist of having an InputDocument and an OutputDocument (and maybe an
>> abstract Document for shared features) such that people wouldn't be
>> confused about calling index time things on Document during search
>> and vice versa.
>
> Maybe don't hold 2.9 for this one? (There's been lots of
> discussion, and also recently interesting discussion on adding type
> safety to Document under LUCENE-831, but nothing yet concrete).
As I said above, I don't see how we can. Either it gets deprecated
now (note, we don't have to have the new version now) or it doesn't
get changed for 3.x is my understanding of the process.
>
>
>> 2. Java 1.5 (who knows, maybe by 2020, we can be on 1.6!). This
>> means we can use Generics, or as I like to call them "Specifics"
>> since the specifically say what is in the collection as opposed to
>> the current collections where you can put any generic object in
>> them. :-)
>
> We get this one "for free" ;)
Of course.
>
>
>> 3. Michael B. is proposing a new Token API (but it's back compat.)
>
> Already in and quite a big cutover.
>
>> 4. Mike M. is doing some new flex indexing stuff (but it's back
>> compat.)
>
> I would not hold 3.0 for this; it's still big & exploratory at this
> point.
Again, merely making the point that if we are going to have API
changes, we need to deprecate now.
>
>
>> 5. Is there anything we would need to deprecate now if we were to
>> take advantage of 1.5 concurrent packages?
>
> Has anyone looked into this?
>
>> 6. Local Lucene is of interest to a lot of people. Does it require
>> anything special in terms of deprecation? (me thinks not)
>
> Any more clarity on this? I would also assume not.
>
>> 7. Same goes for the real time stuff, PFOR implementation, column-
>> stride fields, etc.
>
> I think we tackle real-time needs one by one (eg LUCENE-1484,
> removing sync on IndexReader.document(), which I'm working on now,
> doesn't deprecate anything). PFOR I think is blocked by flex
> indexing. Column-stride fields would be great to get it, but
> doesn't seem to have any forward motion for quite a while...
>
>> 8. I think we should do a review of what's open in JIRA again and
>> see if we can come to conclusions on any of them, such that going
>> into 3.0, JIRA is relatively clean.
>
> I've been trying over time to mark things as fix version 2.9, so we
> are at least forced to review them come 2.9.
>
>> 9. For 3.0, what cruft from 1.x can we remove from the file format,
>> since 3.x need not read 1.x format _if_ doing so is advantageous to
>> us?
>
> I'm not sure offhand. There's alot of scary cruft in
> SegmentInfo.files(), but it's from 2.0 -> 2.1 so we need to keep it
> for now (to remove in 4.0, in 2020 ;) ).
>
>> 10. There has been some talk about changing how StandardTokenizer
>> labels some tokens. What can we do in there to deprecate?
>
> I think we need a more incremental approach, somehow, for
> StandardTokenizer. Like it does its own internal versioning or
> something. There have been lots of little cases over time where it
> needs fixing, yet, it would be a break in back compat to fix them.
>
>> 11. Fieldable. Ah, Fieldable. I believe this is going to become
>> an abstract base class, or go away.
>
> This is a biggie and nobody's stepped up so far to tackle it... I
> would say don't hold up 2.9 for this.
>
We could deprecate for now.
>
> Maybe add these ones:
>
> 12. LUCENE-1483 -- running Scorer & HitCollector "per segment". We
> are making good progress here, and uncovering some nice per-query
> performance wins plus much faster searcher warming (sicne FieldCache
> is only used per-segment). On the current path it looks likely to
> deprecate current Field sorting classes, so it'd be great to get
> this in before 2.9.
>
> 13. LUCENE-831 (new FieldCache API). This is long standing and
> there's a fair amount of interest, and through our iterations with
> LUCENE-1483 (one of the primary users of the FieldCache API, field
> sorting) we are getting more clarity on what a new FieldCache API
> should look like. It'd be nice to resolve before 2.9, and I'd like
> to spend time doing so (after / with LUCENE-1483).
Agreed.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: 2.9, 3.0 and deprecation
Posted by Jason Rutherglen <ja...@gmail.com>.
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 <
lucene@mikemccandless.com> 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 even been started yet.
>
> One question: I'm assuming after 2.9 is out, we would fairly quickly
> follow that up with a 3.0 that has more or less just removed deprecations?
> (Vs doing alot of dev putting new features into 3.0 as well).
>
> More comments below:
>
> Grant Ingersoll wrote:
>
> 1. Splitting Index time Document from Search time Document per Hoss' ideas
>> on a variety of threads in the past. Something to the gist of having an
>> InputDocument and an OutputDocument (and maybe an abstract Document for
>> shared features) such that people wouldn't be confused about calling index
>> time things on Document during search and vice versa.
>>
>
> Maybe don't hold 2.9 for this one? (There's been lots of discussion, and
> also recently interesting discussion on adding type safety to Document under
> LUCENE-831, but nothing yet concrete).
>
> 2. Java 1.5 (who knows, maybe by 2020, we can be on 1.6!). This means we
>> can use Generics, or as I like to call them "Specifics" since the
>> specifically say what is in the collection as opposed to the current
>> collections where you can put any generic object in them. :-)
>>
>
> We get this one "for free" ;)
>
> 3. Michael B. is proposing a new Token API (but it's back compat.)
>>
>
> Already in and quite a big cutover.
>
> 4. Mike M. is doing some new flex indexing stuff (but it's back compat.)
>>
>
> I would not hold 3.0 for this; it's still big & exploratory at this point.
>
> 5. Is there anything we would need to deprecate now if we were to take
>> advantage of 1.5 concurrent packages?
>>
>
> Has anyone looked into this?
>
> 6. Local Lucene is of interest to a lot of people. Does it require
>> anything special in terms of deprecation? (me thinks not)
>>
>
> Any more clarity on this? I would also assume not.
>
> 7. Same goes for the real time stuff, PFOR implementation, column-stride
>> fields, etc.
>>
>
> I think we tackle real-time needs one by one (eg LUCENE-1484, removing sync
> on IndexReader.document(), which I'm working on now, doesn't deprecate
> anything). PFOR I think is blocked by flex indexing. Column-stride fields
> would be great to get it, but doesn't seem to have any forward motion for
> quite a while...
>
> 8. I think we should do a review of what's open in JIRA again and see if
>> we can come to conclusions on any of them, such that going into 3.0, JIRA is
>> relatively clean.
>>
>
> I've been trying over time to mark things as fix version 2.9, so we are at
> least forced to review them come 2.9.
>
> 9. For 3.0, what cruft from 1.x can we remove from the file format, since
>> 3.x need not read 1.x format _if_ doing so is advantageous to us?
>>
>
> I'm not sure offhand. There's alot of scary cruft in SegmentInfo.files(),
> but it's from 2.0 -> 2.1 so we need to keep it for now (to remove in 4.0, in
> 2020 ;) ).
>
> 10. There has been some talk about changing how StandardTokenizer labels
>> some tokens. What can we do in there to deprecate?
>>
>
> I think we need a more incremental approach, somehow, for
> StandardTokenizer. Like it does its own internal versioning or something.
> There have been lots of little cases over time where it needs fixing, yet,
> it would be a break in back compat to fix them.
>
> 11. Fieldable. Ah, Fieldable. I believe this is going to become an
>> abstract base class, or go away.
>>
>
> This is a biggie and nobody's stepped up so far to tackle it... I would say
> don't hold up 2.9 for this.
>
>
> Maybe add these ones:
>
> 12. LUCENE-1483 -- running Scorer & HitCollector "per segment". We are
> making good progress here, and uncovering some nice per-query performance
> wins plus much faster searcher warming (sicne FieldCache is only used
> per-segment). On the current path it looks likely to deprecate current
> Field sorting classes, so it'd be great to get this in before 2.9.
>
> 13. LUCENE-831 (new FieldCache API). This is long standing and there's a
> fair amount of interest, and through our iterations with LUCENE-1483 (one of
> the primary users of the FieldCache API, field sorting) we are getting more
> clarity on what a new FieldCache API should look like. It'd be nice to
> resolve before 2.9, and I'd like to spend time doing so (after / with
> LUCENE-1483).
>
> Mike
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
Re: 2.9, 3.0 and deprecation
Posted by Jason Rutherglen <ja...@gmail.com>.
> 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 <
lucene@mikemccandless.com> 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 even been started yet.
>
> One question: I'm assuming after 2.9 is out, we would fairly quickly
> follow that up with a 3.0 that has more or less just removed deprecations?
> (Vs doing alot of dev putting new features into 3.0 as well).
>
> More comments below:
>
> Grant Ingersoll wrote:
>
> 1. Splitting Index time Document from Search time Document per Hoss' ideas
>> on a variety of threads in the past. Something to the gist of having an
>> InputDocument and an OutputDocument (and maybe an abstract Document for
>> shared features) such that people wouldn't be confused about calling index
>> time things on Document during search and vice versa.
>>
>
> Maybe don't hold 2.9 for this one? (There's been lots of discussion, and
> also recently interesting discussion on adding type safety to Document under
> LUCENE-831, but nothing yet concrete).
>
> 2. Java 1.5 (who knows, maybe by 2020, we can be on 1.6!). This means we
>> can use Generics, or as I like to call them "Specifics" since the
>> specifically say what is in the collection as opposed to the current
>> collections where you can put any generic object in them. :-)
>>
>
> We get this one "for free" ;)
>
> 3. Michael B. is proposing a new Token API (but it's back compat.)
>>
>
> Already in and quite a big cutover.
>
> 4. Mike M. is doing some new flex indexing stuff (but it's back compat.)
>>
>
> I would not hold 3.0 for this; it's still big & exploratory at this point.
>
> 5. Is there anything we would need to deprecate now if we were to take
>> advantage of 1.5 concurrent packages?
>>
>
> Has anyone looked into this?
>
> 6. Local Lucene is of interest to a lot of people. Does it require
>> anything special in terms of deprecation? (me thinks not)
>>
>
> Any more clarity on this? I would also assume not.
>
> 7. Same goes for the real time stuff, PFOR implementation, column-stride
>> fields, etc.
>>
>
> I think we tackle real-time needs one by one (eg LUCENE-1484, removing sync
> on IndexReader.document(), which I'm working on now, doesn't deprecate
> anything). PFOR I think is blocked by flex indexing. Column-stride fields
> would be great to get it, but doesn't seem to have any forward motion for
> quite a while...
>
> 8. I think we should do a review of what's open in JIRA again and see if
>> we can come to conclusions on any of them, such that going into 3.0, JIRA is
>> relatively clean.
>>
>
> I've been trying over time to mark things as fix version 2.9, so we are at
> least forced to review them come 2.9.
>
> 9. For 3.0, what cruft from 1.x can we remove from the file format, since
>> 3.x need not read 1.x format _if_ doing so is advantageous to us?
>>
>
> I'm not sure offhand. There's alot of scary cruft in SegmentInfo.files(),
> but it's from 2.0 -> 2.1 so we need to keep it for now (to remove in 4.0, in
> 2020 ;) ).
>
> 10. There has been some talk about changing how StandardTokenizer labels
>> some tokens. What can we do in there to deprecate?
>>
>
> I think we need a more incremental approach, somehow, for
> StandardTokenizer. Like it does its own internal versioning or something.
> There have been lots of little cases over time where it needs fixing, yet,
> it would be a break in back compat to fix them.
>
> 11. Fieldable. Ah, Fieldable. I believe this is going to become an
>> abstract base class, or go away.
>>
>
> This is a biggie and nobody's stepped up so far to tackle it... I would say
> don't hold up 2.9 for this.
>
>
> Maybe add these ones:
>
> 12. LUCENE-1483 -- running Scorer & HitCollector "per segment". We are
> making good progress here, and uncovering some nice per-query performance
> wins plus much faster searcher warming (sicne FieldCache is only used
> per-segment). On the current path it looks likely to deprecate current
> Field sorting classes, so it'd be great to get this in before 2.9.
>
> 13. LUCENE-831 (new FieldCache API). This is long standing and there's a
> fair amount of interest, and through our iterations with LUCENE-1483 (one of
> the primary users of the FieldCache API, field sorting) we are getting more
> clarity on what a new FieldCache API should look like. It'd be nice to
> resolve before 2.9, and I'd like to spend time doing so (after / with
> LUCENE-1483).
>
> Mike
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
Re: 2.9, 3.0 and deprecation
Posted by Michael McCandless <lu...@mikemccandless.com>.
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 2.9 is out, we would fairly quickly
follow that up with a 3.0 that has more or less just removed
deprecations?
(Vs doing alot of dev putting new features into 3.0 as well).
More comments below:
Grant Ingersoll wrote:
> 1. Splitting Index time Document from Search time Document per Hoss'
> ideas on a variety of threads in the past. Something to the gist of
> having an InputDocument and an OutputDocument (and maybe an abstract
> Document for shared features) such that people wouldn't be confused
> about calling index time things on Document during search and vice
> versa.
Maybe don't hold 2.9 for this one? (There's been lots of discussion,
and also recently interesting discussion on adding type safety to
Document under LUCENE-831, but nothing yet concrete).
> 2. Java 1.5 (who knows, maybe by 2020, we can be on 1.6!). This
> means we can use Generics, or as I like to call them "Specifics"
> since the specifically say what is in the collection as opposed to
> the current collections where you can put any generic object in
> them. :-)
We get this one "for free" ;)
> 3. Michael B. is proposing a new Token API (but it's back compat.)
Already in and quite a big cutover.
> 4. Mike M. is doing some new flex indexing stuff (but it's back
> compat.)
I would not hold 3.0 for this; it's still big & exploratory at this
point.
> 5. Is there anything we would need to deprecate now if we were to
> take advantage of 1.5 concurrent packages?
Has anyone looked into this?
> 6. Local Lucene is of interest to a lot of people. Does it require
> anything special in terms of deprecation? (me thinks not)
Any more clarity on this? I would also assume not.
> 7. Same goes for the real time stuff, PFOR implementation, column-
> stride fields, etc.
I think we tackle real-time needs one by one (eg LUCENE-1484, removing
sync on IndexReader.document(), which I'm working on now, doesn't
deprecate anything). PFOR I think is blocked by flex indexing.
Column-stride fields would be great to get it, but doesn't seem to
have any forward motion for quite a while...
> 8. I think we should do a review of what's open in JIRA again and
> see if we can come to conclusions on any of them, such that going
> into 3.0, JIRA is relatively clean.
I've been trying over time to mark things as fix version 2.9, so we
are at least forced to review them come 2.9.
> 9. For 3.0, what cruft from 1.x can we remove from the file format,
> since 3.x need not read 1.x format _if_ doing so is advantageous to
> us?
I'm not sure offhand. There's alot of scary cruft in
SegmentInfo.files(), but it's from 2.0 -> 2.1 so we need to keep it
for now (to remove in 4.0, in 2020 ;) ).
> 10. There has been some talk about changing how StandardTokenizer
> labels some tokens. What can we do in there to deprecate?
I think we need a more incremental approach, somehow, for
StandardTokenizer. Like it does its own internal versioning or
something. There have been lots of little cases over time where it
needs fixing, yet, it would be a break in back compat to fix them.
> 11. Fieldable. Ah, Fieldable. I believe this is going to become an
> abstract base class, or go away.
This is a biggie and nobody's stepped up so far to tackle it... I
would say don't hold up 2.9 for this.
Maybe add these ones:
12. LUCENE-1483 -- running Scorer & HitCollector "per segment". We
are making good progress here, and uncovering some nice per-query
performance wins plus much faster searcher warming (sicne FieldCache
is only used per-segment). On the current path it looks likely to
deprecate current Field sorting classes, so it'd be great to get this
in before 2.9.
13. LUCENE-831 (new FieldCache API). This is long standing and
there's a fair amount of interest, and through our iterations with
LUCENE-1483 (one of the primary users of the FieldCache API, field
sorting) we are getting more clarity on what a new FieldCache API
should look like. It'd be nice to resolve before 2.9, and I'd like to
spend time doing so (after / with LUCENE-1483).
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org