On Mon, May 16, 2011 at 7:52 AM, Simon Willnauer <simon.willna...@googlemail.com> 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 APIs. * 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
