lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Muir <>
Subject Re: Lucene 4.x release
Date Wed, 17 Aug 2011 00:54:15 GMT
the postings api.

On Tue, Aug 16, 2011 at 8:24 PM, Jason Rutherglen
<> wrote:
> I didn't know the bulk API was so important.  Which bulk API (eg the
> postings one or the terms dict)?
> On Mon, Aug 15, 2011 at 11:17 PM, Robert Muir <> wrote:
>> On Mon, Aug 15, 2011 at 10:49 PM, Mark Miller <> wrote:
>>> Just throwing this out there, but:
>>> I think it would be really cool if we could get 4.0 out by the end of the year.
>>> With such a large release, I think it would also make a lot of sense if we tried
a more formal beta release, just to increase the amount of usage before we officially sign
off on a final 4.0.
>> I agree with the beta idea, I think its really necessary actually: we
>> are just being honest at that point that its a real point-zero
>> release.
>> on the other hand, besides the GSOC stuff, I think we should
>> accomplish a few things first to ensure we can actually make the 4.x
>> release useful and issue minor releases off of it:
>> * fix the bulk API: otherwise we only have "flexible indexing, as long
>> as you don't mind flexible == slower". This is really important, I
>> dont think we have to implement a bunch of new compression algorithms
>> but the whole postings APIs are suboptimal, and biased towards
>> lucene's current format: the bulk APIs arent low level enough to give
>> good performance, the payloads APIs assume you can ask for a payload
>> at any time (they assume basically that you are going to 'steal bits'
>> from the positions like we do today), etc etc.
>> * round out docvalues, especially merging with different docvalues
>> types and things like that. arguably these are nocommits... I think
>> you will get an exception during merge? I also think its bad we still
>> don't use docvalues for norms nor the faceting module, fixing these
>> kinds of real world uses is probably a great way to round this out.
>> * figure out the packaging system for modules such that things like
>> clover/hudson/javadocs etc all work across them (not quite today). We
>> also need to look at all the minor things like CHANGES.txt and such...
>> there are too many of these. Furthermore at least I wanted the
>> analyzers modularization to move forward to a point where we can
>> remove the Version crap and you just use the old jar file, I don't
>> feel like we are even close to that.
>> * fix codec naming: i think its silly to name a codec "Standard" and
>> use the codec header for backwards compatibility, easier to name the
>> codec "Standard40" and just package this codec in the next release for
>> backwards compatibility, e.g. if we want to introduce a new index
>> format we make it "Standard42". This is just my opinion though, its
>> not the only way to solve the index backwards compat here but I think
>> its easiest.
>> I have a ton more pet peeves, but I think these are the biggest. It
>> probably sounds like a lot but I think its totally stupid to release
>> 4.0 if we cannot "grow" the 4.x branch with 4.1, 4.2, etc while we
>> work on 5.x. Otherwise we are just jumping from 4.0 to 5.0 and thats a
>> sign we just shouldnt have released at all.
>> --
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message