lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Rutherglen <>
Subject Re: Lucene 4.x release
Date Wed, 17 Aug 2011 00:24:26 GMT
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:

View raw message