On 6/19/06, Chuck Williams <[EMAIL PROTECTED]> wrote:
Ray Tsang wrote on 06/19/2006 09:06 AM: > On 6/17/06, Chuck Williams <[EMAIL PROTECTED]> wrote: >> >> Ray Tsang wrote on 06/17/2006 06:29 AM: >> > I think the problem right now isn't whether we are going to have 1.5 >> > code or not. We will eventually have to have 1.5 code anyways. But >> > we need a sound plan that will make the transition easy. I believe >> > the transition from 1.4 to 1.5 is not an over night thing. >> >> I disagree. 1.5 was specifically designed to make transition easy, >> including the inclusion of "non-features" that ensure smooth >> interoperability (e.g., raw types and no runtime presence whatsoever of >> generics -- quite different from how it was done in .Net 2.0 for >> example). > > But will 1.4 jvm be able to run the new Lucene w/ 1.5 core? If 1.5 features are fully embraced, no. > >> >> > >> > Secondly can we specifically find places where some people _will_ >> > contribute code immediately if it's 1.5 is accepted? >> >> I already have. That's what started this second round of debate. > > What is it? ParallelWriter (see LUCENE-600). I have quite a few more behind that. Whether or not various people will find them useful is tbd, but they are all working well for me and essential to meet my requirements, and some are for things often requested on the various lists (e.g., a general purpose fast bulk index updater that supports arbitrary transformations on the values of fields).
That sounds great actually! Would you say it does not necessarily need to go into the core? I would use something like that though.
> Who else? How many? Do we have statistics? We have > statistics of number of users between 1.4 vs. 1.5 (which btw didn't > present a significant polarization), but how about actual numbers > potential of contributions between the 2? There has been a proposal to poll java-dev for this. Wagers on the outcome? > >> >> > >> > Like what I have suggested before, why not have contribution modules >> > that act as a transition into 1.5 code? Much like what other >> > framework has a "tiger" module. This module may have say, a 1.5 >> > compatible layer on top of 1.4 core, or other components of lucene >> > that was made to be extensible, e.g. 1.5 version of QueryParser, >> > Directory, etc. >> >> I think this would make it unnecessarily complex. > > How is it unnecessary or complex? If it only means layering, > extending classes, adding implementations, it should be relatively > easy with the existing design. It's something we do everyday > regardless what lucene's direction takes. Contributing to Lucene is a volunteer effort. The more difficult you make it, the fewer people will do it. That's what this is all about. Accept 1.5 contributions and I believe you will get more high quality contributions. Of course, this comes at a high cost for those who cannot transition to 1.5, since they would need to stick with Lucene 2.0.x.
Don't get me wrong. My point is _not_ not to accept 1.5 code. By all means we should accept it. But it'll be better if there is a simple way to accept it while at least majority of lucene-core.jar is compatible w/ 1.4 at bytecode level, while, say, lucene-tiger.jar are add ons for full 1.5 specific code that will not be bytecode compatible with 1.4?
If I had a vote on this, honestly I'm not sure how I would vote. It's a tough call either way. Do you support a significant minority of users and contributors who are stuck on an old java platform, or do you strike forward with a more robust contributing community from the majority at the cost of cutting out the minority from the latest and greatest? My first comment on this topic was something like, "why would somebody who is on an old java platform expect to have the latest and greatest lucene?". I think if I was stuck on 1.4, I wouldn't be happy about a 1.5 decision for lucene 2.1+, but I would understand it, accept it, and do whatever I could to speed my transition to 1.5.
I would agree, but i'm sure there can be compromises.
Chuck --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
