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 < luc...@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-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > >
