Release schedule Lucene 4?

[Gregor Heinrich <gr...@arbylon.net>]

Dear Lucene team,

I am wondering whether there is an updated Lucene release schedule for the v4.0 
stream.

Any earliest/latest alpha/beta/stable date? And if not yet, where to track such 
info?

Thanks in advance from Germany

gregor

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Release schedule Lucene 4?

[Shai Erera <se...@gmail.com>]

Well … we can decide on a list of features we want in 4.0 (e.g., fhe 3
you mention above), estimate the time it would take to finish them and
then give a release date(s). That will get is faster to a release than
if we wait for all JIRA issues to end + the separate branches we work
on.

We should also decide on a release date for 3x.

And as usual, we should release more often than we do today :).

Shai

On Saturday, January 15, 2011, Michael McCandless
<lu...@mikemccandless.com> wrote:
> This is unfortunately hard to say!
>
> There's tons of good stuff in 4.0, so we'd really like to release
> sooner rather than later.
>
> But then there's also alot of work remaining, eg we have 3 feature
> branches in flight right now, that we need to wrap up and land on
> trunk:
>
>   * realtime (gives us concurrent flushing during indexing)
>
>   * docvalues (adds column-stride fields)
>
>   * bulkpostings (gives good search speedup for intblock codecs)
>
> Plus many open Jira issues.  So it's hard to predict when all of this
> will be done....
>
> Mike
>
> On Fri, Jan 14, 2011 at 12:31 PM, Gregor Heinrich <gr...@arbylon.net> wrote:
>> Dear Lucene team,
>>
>> I am wondering whether there is an updated Lucene release schedule for the
>> v4.0 stream.
>>
>> Any earliest/latest alpha/beta/stable date? And if not yet, where to track
>> such info?
>>
>> Thanks in advance from Germany
>>
>> gregor
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Release schedule Lucene 4?

[Michael McCandless <lu...@mikemccandless.com>]

I am hoping that it'll be in 2011... but don't hold me to that.  It's
really not possible to predict!

You can always use a trunk version and give feedback :)

But beware that it's "unsable", meaning APIs and the index format can
suddenly change.

Mike

On Mon, Jan 17, 2011 at 8:51 AM, Gregor Heinrich <gr...@arbylon.net> wrote:
> Hi Mike, all --
>
> a (sorrily slow) thanks for this response ;)
>
> From the ensuing discussion, it sounds like there's a LOT to be in v4, and
> not raising wrong expectation by giving dates is appreciated ;)
>
> Only thing is, are we talking any time in 2012 or 2011, just to have a
> coarse-grained estimate without any assumptions attached?
>
> Best
>
> gregor
>
>
>
>
>
> On 1/15/11 3:20 PM, Michael McCandless wrote:
>>
>> This is unfortunately hard to say!
>>
>> There's tons of good stuff in 4.0, so we'd really like to release
>> sooner rather than later.
>>
>> But then there's also alot of work remaining, eg we have 3 feature
>> branches in flight right now, that we need to wrap up and land on
>> trunk:
>>
>>   * realtime (gives us concurrent flushing during indexing)
>>
>>   * docvalues (adds column-stride fields)
>>
>>   * bulkpostings (gives good search speedup for intblock codecs)
>>
>> Plus many open Jira issues.  So it's hard to predict when all of this
>> will be done....
>>
>> Mike
>>
>> On Fri, Jan 14, 2011 at 12:31 PM, Gregor Heinrich<gr...@arbylon.net>
>>  wrote:
>>>
>>> Dear Lucene team,
>>>
>>> I am wondering whether there is an updated Lucene release schedule for
>>> the
>>> v4.0 stream.
>>>
>>> Any earliest/latest alpha/beta/stable date? And if not yet, where to
>>> track
>>> such info?
>>>
>>> Thanks in advance from Germany
>>>
>>> gregor
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Release schedule Lucene 4?

[Gregor Heinrich <gr...@arbylon.net>]

Hi Mike, all --

a (sorrily slow) thanks for this response ;)

 From the ensuing discussion, it sounds like there's a LOT to be in v4, and not 
raising wrong expectation by giving dates is appreciated ;)

Only thing is, are we talking any time in 2012 or 2011, just to have a 
coarse-grained estimate without any assumptions attached?

Best

gregor





On 1/15/11 3:20 PM, Michael McCandless wrote:
> This is unfortunately hard to say!
>
> There's tons of good stuff in 4.0, so we'd really like to release
> sooner rather than later.
>
> But then there's also alot of work remaining, eg we have 3 feature
> branches in flight right now, that we need to wrap up and land on
> trunk:
>
>    * realtime (gives us concurrent flushing during indexing)
>
>    * docvalues (adds column-stride fields)
>
>    * bulkpostings (gives good search speedup for intblock codecs)
>
> Plus many open Jira issues.  So it's hard to predict when all of this
> will be done....
>
> Mike
>
> On Fri, Jan 14, 2011 at 12:31 PM, Gregor Heinrich<gr...@arbylon.net>  wrote:
>> Dear Lucene team,
>>
>> I am wondering whether there is an updated Lucene release schedule for the
>> v4.0 stream.
>>
>> Any earliest/latest alpha/beta/stable date? And if not yet, where to track
>> such info?
>>
>> Thanks in advance from Germany
>>
>> gregor
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Release schedule Lucene 4?

[Simon Willnauer <si...@googlemail.com>]

On Mon, Jan 17, 2011 at 12:24 PM, Michael McCandless
<lu...@mikemccandless.com> wrote:
> On Sun, Jan 16, 2011 at 11:35 AM, Jason Rutherglen
> <ja...@gmail.com> wrote:
>>> But: they don't yet support updating the values (the goal is to allow
>>> this, eventually).  This is just the first step.
>>
>> No?  Hmm... I thought that was a main part of the functionality?
>
> Patches welcome ;)
>
> Seriously, how would you do it?  IE, I don't like how norms handle it
> today -- on changing a single value we must write the full array (for
> all docs).  Same problem w/ del docs, though since its 1 bit per doc
> the cost is far less.

For some implemenations writing the value directly would be possible
though. For instance for StraightFixedBytes and maybe DerefFixedBytes
(depending on how its indexed) we could do change the value without
writing the entire array. Yet, this would violate the write once
policy! Having this feature in Lucene and having them updateable are
<babystep> vs. <dream> - jason, again Patches welcome but let us first
land it on trunk.

simon
>
> Better would be a stacked approach, where the orig full array remains
> and we write sparse deltas (pairs of docID + new value), and at init
> we load the base and apply all the diffs (in order).  Merging would
> periodically coalesce them down again...
>
> Mike
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Release schedule Lucene 4?

[Jason Rutherglen <ja...@gmail.com>]

> Seriously, how would you do it?

Ah, for LUCENE-2312 we don't need to update existing values, we only
need to make additions, ie, it's not the general use case.  I got the
impression that DocValues should be used instead of CSF?  Does CSF
replace the FieldCache usage entirely?

> Better would be a stacked approach, where the orig full array remains
> and we write sparse deltas (pairs of docID + new value)

What is the lookup cost using this method?

On Mon, Jan 17, 2011 at 3:24 AM, Michael McCandless
<lu...@mikemccandless.com> wrote:
> On Sun, Jan 16, 2011 at 11:35 AM, Jason Rutherglen
> <ja...@gmail.com> wrote:
>>> But: they don't yet support updating the values (the goal is to allow
>>> this, eventually).  This is just the first step.
>>
>> No?  Hmm... I thought that was a main part of the functionality?
>
> Patches welcome ;)
>
> Seriously, how would you do it?  IE, I don't like how norms handle it
> today -- on changing a single value we must write the full array (for
> all docs).  Same problem w/ del docs, though since its 1 bit per doc
> the cost is far less.
>
> Better would be a stacked approach, where the orig full array remains
> and we write sparse deltas (pairs of docID + new value), and at init
> we load the base and apply all the diffs (in order).  Merging would
> periodically coalesce them down again...
>
> Mike
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Release schedule Lucene 4?

[Michael McCandless <lu...@mikemccandless.com>]

Yes!

Mike

On Mon, Jan 17, 2011 at 7:47 AM, Shai Erera <se...@gmail.com> wrote:
> This sounds like incremental field updates :).
>
> Shai
>
> On Mon, Jan 17, 2011 at 1:24 PM, Michael McCandless
> <lu...@mikemccandless.com> wrote:
>>
>> On Sun, Jan 16, 2011 at 11:35 AM, Jason Rutherglen
>> <ja...@gmail.com> wrote:
>> >> But: they don't yet support updating the values (the goal is to allow
>> >> this, eventually).  This is just the first step.
>> >
>> > No?  Hmm... I thought that was a main part of the functionality?
>>
>> Patches welcome ;)
>>
>> Seriously, how would you do it?  IE, I don't like how norms handle it
>> today -- on changing a single value we must write the full array (for
>> all docs).  Same problem w/ del docs, though since its 1 bit per doc
>> the cost is far less.
>>
>> Better would be a stacked approach, where the orig full array remains
>> and we write sparse deltas (pairs of docID + new value), and at init
>> we load the base and apply all the diffs (in order).  Merging would
>> periodically coalesce them down again...
>>
>> Mike
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Release schedule Lucene 4?

[Shai Erera <se...@gmail.com>]

This sounds like incremental field updates :).

Shai

On Mon, Jan 17, 2011 at 1:24 PM, Michael McCandless <
lucene@mikemccandless.com> wrote:

> On Sun, Jan 16, 2011 at 11:35 AM, Jason Rutherglen
> <ja...@gmail.com> wrote:
> >> But: they don't yet support updating the values (the goal is to allow
> >> this, eventually).  This is just the first step.
> >
> > No?  Hmm... I thought that was a main part of the functionality?
>
> Patches welcome ;)
>
> Seriously, how would you do it?  IE, I don't like how norms handle it
> today -- on changing a single value we must write the full array (for
> all docs).  Same problem w/ del docs, though since its 1 bit per doc
> the cost is far less.
>
> Better would be a stacked approach, where the orig full array remains
> and we write sparse deltas (pairs of docID + new value), and at init
> we load the base and apply all the diffs (in order).  Merging would
> periodically coalesce them down again...
>
> Mike
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>

Re: Release schedule Lucene 4?

[Jason Rutherglen <ja...@gmail.com>]

> Better would be a stacked approach, where the orig full array remains
> and we write sparse deltas (pairs of docID + new value), and at init
> we load the base and apply all the diffs (in order).  Merging would
> periodically coalesce them down again...

I think this approach would be great for the DF in RT.   It's better
than a multidimensional array?  As the lookup cost won't be too high,
and we can instantiate a new main int[] every N.   I'll enumerate the
options we've gone over in the LUCENE-2312 issue, so we don't forget!

On Mon, Jan 17, 2011 at 3:24 AM, Michael McCandless
<lu...@mikemccandless.com> wrote:
> On Sun, Jan 16, 2011 at 11:35 AM, Jason Rutherglen
> <ja...@gmail.com> wrote:
>>> But: they don't yet support updating the values (the goal is to allow
>>> this, eventually).  This is just the first step.
>>
>> No?  Hmm... I thought that was a main part of the functionality?
>
> Patches welcome ;)
>
> Seriously, how would you do it?  IE, I don't like how norms handle it
> today -- on changing a single value we must write the full array (for
> all docs).  Same problem w/ del docs, though since its 1 bit per doc
> the cost is far less.
>
> Better would be a stacked approach, where the orig full array remains
> and we write sparse deltas (pairs of docID + new value), and at init
> we load the base and apply all the diffs (in order).  Merging would
> periodically coalesce them down again...
>
> Mike
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Release schedule Lucene 4?

[Michael McCandless <lu...@mikemccandless.com>]

On Sun, Jan 16, 2011 at 11:35 AM, Jason Rutherglen
<ja...@gmail.com> wrote:
>> But: they don't yet support updating the values (the goal is to allow
>> this, eventually).  This is just the first step.
>
> No?  Hmm... I thought that was a main part of the functionality?

Patches welcome ;)

Seriously, how would you do it?  IE, I don't like how norms handle it
today -- on changing a single value we must write the full array (for
all docs).  Same problem w/ del docs, though since its 1 bit per doc
the cost is far less.

Better would be a stacked approach, where the orig full array remains
and we write sparse deltas (pairs of docID + new value), and at init
we load the base and apply all the diffs (in order).  Merging would
periodically coalesce them down again...

Mike

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Release schedule Lucene 4?

[Jason Rutherglen <ja...@gmail.com>]

> But: they don't yet support updating the values (the goal is to allow
> this, eventually).  This is just the first step.

No?  Hmm... I thought that was a main part of the functionality?

On Sun, Jan 16, 2011 at 6:07 AM, Michael McCandless
<lu...@mikemccandless.com> wrote:
> Actually docvalues is like field cache, in that you can quickly look
> up a value from a docID, except the values are stored in the index
> directory and then loaded into RAM by SegmentReader.
>
> So eg while FieldCache must "uninvert" to create the array, doc values
> are just loaded.
>
> Doc values are also more efficient in some cases.  EG, when storing
> byte[] per doc, you can state whether it should be deref'd (which
> you'd do for an enum'd field, eg "Country"), or stored directly (which
> you should do for a field that won't have many dups, eg "Title").
>
> But: they don't yet support updating the values (the goal is to allow
> this, eventually).  This is just the first step.
>
> In the future, we may also cutover norms -> doc values, and likely use
> them to hold the raw measures (field/doc boost, doc number of tokens,
> doc avg tf., etc.) for flex scoring.
>
> Mike
>
> On Sun, Jan 16, 2011 at 6:53 AM, Li Li <fa...@gmail.com> wrote:
>> does docvalues (adds column-stride fields)  means stored but not indexed fields
>>  which can be modified while do not need reindex?
>> we simply implemented this based on lucene 2.9.1 and integrated it into solr 1.4
>> it works well for short fields such as "click count", "page rank" etc.
>> these values
>> changed very quickly. the only problem of our implementation is that it can not
>> work well with compound file format(cfs).
>>
>>
>>
>> 2011/1/15 Michael McCandless <lu...@mikemccandless.com>:
>>> This is unfortunately hard to say!
>>>
>>> There's tons of good stuff in 4.0, so we'd really like to release
>>> sooner rather than later.
>>>
>>> But then there's also alot of work remaining, eg we have 3 feature
>>> branches in flight right now, that we need to wrap up and land on
>>> trunk:
>>>
>>>  * realtime (gives us concurrent flushing during indexing)
>>>
>>>  * docvalues (adds column-stride fields)
>>>
>>>  * bulkpostings (gives good search speedup for intblock codecs)
>>>
>>> Plus many open Jira issues.  So it's hard to predict when all of this
>>> will be done....
>>>
>>> Mike
>>>
>>> On Fri, Jan 14, 2011 at 12:31 PM, Gregor Heinrich <gr...@arbylon.net> wrote:
>>>> Dear Lucene team,
>>>>
>>>> I am wondering whether there is an updated Lucene release schedule for the
>>>> v4.0 stream.
>>>>
>>>> Any earliest/latest alpha/beta/stable date? And if not yet, where to track
>>>> such info?
>>>>
>>>> Thanks in advance from Germany
>>>>
>>>> gregor
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Release schedule Lucene 4?

[Michael McCandless <lu...@mikemccandless.com>]

Actually docvalues is like field cache, in that you can quickly look
up a value from a docID, except the values are stored in the index
directory and then loaded into RAM by SegmentReader.

So eg while FieldCache must "uninvert" to create the array, doc values
are just loaded.

Doc values are also more efficient in some cases.  EG, when storing
byte[] per doc, you can state whether it should be deref'd (which
you'd do for an enum'd field, eg "Country"), or stored directly (which
you should do for a field that won't have many dups, eg "Title").

But: they don't yet support updating the values (the goal is to allow
this, eventually).  This is just the first step.

In the future, we may also cutover norms -> doc values, and likely use
them to hold the raw measures (field/doc boost, doc number of tokens,
doc avg tf., etc.) for flex scoring.

Mike

On Sun, Jan 16, 2011 at 6:53 AM, Li Li <fa...@gmail.com> wrote:
> does docvalues (adds column-stride fields)  means stored but not indexed fields
>  which can be modified while do not need reindex?
> we simply implemented this based on lucene 2.9.1 and integrated it into solr 1.4
> it works well for short fields such as "click count", "page rank" etc.
> these values
> changed very quickly. the only problem of our implementation is that it can not
> work well with compound file format(cfs).
>
>
>
> 2011/1/15 Michael McCandless <lu...@mikemccandless.com>:
>> This is unfortunately hard to say!
>>
>> There's tons of good stuff in 4.0, so we'd really like to release
>> sooner rather than later.
>>
>> But then there's also alot of work remaining, eg we have 3 feature
>> branches in flight right now, that we need to wrap up and land on
>> trunk:
>>
>>  * realtime (gives us concurrent flushing during indexing)
>>
>>  * docvalues (adds column-stride fields)
>>
>>  * bulkpostings (gives good search speedup for intblock codecs)
>>
>> Plus many open Jira issues.  So it's hard to predict when all of this
>> will be done....
>>
>> Mike
>>
>> On Fri, Jan 14, 2011 at 12:31 PM, Gregor Heinrich <gr...@arbylon.net> wrote:
>>> Dear Lucene team,
>>>
>>> I am wondering whether there is an updated Lucene release schedule for the
>>> v4.0 stream.
>>>
>>> Any earliest/latest alpha/beta/stable date? And if not yet, where to track
>>> such info?
>>>
>>> Thanks in advance from Germany
>>>
>>> gregor
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Release schedule Lucene 4?

[Li Li <fa...@gmail.com>]

does docvalues (adds column-stride fields)  means stored but not indexed fields
 which can be modified while do not need reindex?
we simply implemented this based on lucene 2.9.1 and integrated it into solr 1.4
it works well for short fields such as "click count", "page rank" etc.
these values
changed very quickly. the only problem of our implementation is that it can not
work well with compound file format(cfs).



2011/1/15 Michael McCandless <lu...@mikemccandless.com>:
> This is unfortunately hard to say!
>
> There's tons of good stuff in 4.0, so we'd really like to release
> sooner rather than later.
>
> But then there's also alot of work remaining, eg we have 3 feature
> branches in flight right now, that we need to wrap up and land on
> trunk:
>
>  * realtime (gives us concurrent flushing during indexing)
>
>  * docvalues (adds column-stride fields)
>
>  * bulkpostings (gives good search speedup for intblock codecs)
>
> Plus many open Jira issues.  So it's hard to predict when all of this
> will be done....
>
> Mike
>
> On Fri, Jan 14, 2011 at 12:31 PM, Gregor Heinrich <gr...@arbylon.net> wrote:
>> Dear Lucene team,
>>
>> I am wondering whether there is an updated Lucene release schedule for the
>> v4.0 stream.
>>
>> Any earliest/latest alpha/beta/stable date? And if not yet, where to track
>> such info?
>>
>> Thanks in advance from Germany
>>
>> gregor
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Release schedule Lucene 4?

[Michael McCandless <lu...@mikemccandless.com>]

This is unfortunately hard to say!

There's tons of good stuff in 4.0, so we'd really like to release
sooner rather than later.

But then there's also alot of work remaining, eg we have 3 feature
branches in flight right now, that we need to wrap up and land on
trunk:

  * realtime (gives us concurrent flushing during indexing)

  * docvalues (adds column-stride fields)

  * bulkpostings (gives good search speedup for intblock codecs)

Plus many open Jira issues.  So it's hard to predict when all of this
will be done....

Mike

On Fri, Jan 14, 2011 at 12:31 PM, Gregor Heinrich <gr...@arbylon.net> wrote:
> Dear Lucene team,
>
> I am wondering whether there is an updated Lucene release schedule for the
> v4.0 stream.
>
> Any earliest/latest alpha/beta/stable date? And if not yet, where to track
> such info?
>
> Thanks in advance from Germany
>
> gregor
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org