>
> I think we should also start planning for Lucene 4.0 soon.
>

+1 !

I think we should focus on everything that's *infrastructure* in 4.0, so
that we can develop additional features in subsequent 4.x releases. If we
end up releasing 4.0 just to discover many things will need to wait to 5.0,
it'll be a big loss.

So Codecs seem like *infra* to me, and can we make sure the necessary API is
in place for RT Search and stuff? I think a lot of the new API in 4.0 is
@lucene.experimental anyway?

In short, if we have enough API support in 4.0 already, we can release it
and develop features in 4.x releases. The only thing we should 'push' is
stuff that requires API serious changes (I doubt there are many like that,
maybe just Codecs support for the stuff you mentioned).

Shai

On Mon, May 16, 2011 at 2:52 PM, 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)
> - DocValues (pretty close)
> - FlexibleScoring (+- 0 I think we should wait how gsoc turns out and
> decide then?)
> - Codec Support for Stored Fields, Norms & TV (not sure about that but
> seems doable at least an API and current impl as default)
> - Realtime Search aka. Searchable Ram Buffer (this seems quite far
> though while I would love to have it it seems we need to push this to
> > 4.0)
>
> For DocValues the decision seems easy since we are very close with
> that and I expect it to land until end of June. I want to kick off the
> discussion here so nothing will be set to stone really but I think we
> should plan to release somewhere near the end of the year?!
>
>
> simon
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Reply via email to