lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Muir <>
Subject Re: Moving towards Lucene 4.0
Date Mon, 16 May 2011 12:41:55 GMT
On Mon, May 16, 2011 at 7:52 AM, Simon Willnauer
<> wrote:
> Hey folks,
> we just started the discussion about Lucene 3.2 and releasing more
> often. Yet, I think we should also start planning for Lucene 4.0 soon.
> We have tons of stuff in trunk that people want to have and we can't
> just keep on talking about it - we need to push this out to our users.
> From my perspective we should decide on at least the big outstanding
> issues like:
> - BulkPostings (my +1 since I want to enable positional scoring on all queries)

in my own opinion, this is probably the most important to decide how
to handle. I think it might not be good if we introduce a new major
version branch (4.x) with flexible indexing if the postings APIs limit
us from actually taking advantage of it.
I think that we should look at (shai brought up a previous thread
about this) when 4.x is released, 3.x goes into bugfix mode and we
open up 5.x. So, we want to make sure we actually have things stable
enough (from an API and flexibility perspective) that we will be able
to get some life out of the 4.x series and add new features to it.

I think there is a lot left to do with bulkpostings and its going to
require a lot of work, but at the same time I really don't like that
we have serious improvements/features in trunk (some have been there
now for years) still unreleased and not yet available to users.

Some other crazy ideas (just for discussion):
* we could try to be more aggressive about backporting and getting
more "life" out of 3.x, and getting some of these features to users.
For example, perhaps things like DWPT, DocValues, more efficient terms
index, automaton, etc could be backported safely. the advantage here
is that we get the features to the users, but the disadvantage is it
would be a lot of effort backporting.
* we could decide that we do actually have enough flexibility now in
4.x to get several releases out of it (e.g. containing features like
docvalues, realtime search, etc), even though we know its limited to
some extent, and defer api-breakers like bulkpostings/flexscoring to
5.x. the advantage here is that we could start looking at 4.x
releasing very soon, but there are some disadvantages, like forcing
people have to change a lot of their code to upgrade but for less
"gain", and potentially limiting ourselves in the 4.x branch by its
* we could do nothing at all, and keep going like we are going now,
deciding that we are actually getting enough useful features into 3.x
releases that its ok for us to block 4.0 on some of these tougher
issues like bulkpostings. The disadvantage is of course even longer
wait time for the features that have been sitting in trunk a while,
but it keeps 3.x stable and is less work for us.

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

View raw message