Home | About | Sematext search-lucene.com search-hadoop.com
 Search Lucene and all its subprojects:

Switch to Threaded View
Lucene, mail # dev - Lucene 3.3 release soon?
Lukáš Vlček
2011-06-20, 08:56
Simon Willnauer
2011-06-20, 08:59
Lukáš Vlček
2011-06-20, 10:49
Robert Muir
2011-06-20, 11:36
Michael McCandless
2011-06-20, 18:03
Bill Bell
2011-06-21, 03:53
Jan Høydahl
2011-06-21, 08:13
Robert Muir
2011-06-21, 16:09
Simon Willnauer
2011-06-21, 16:53
johnmunir@...
2011-06-21, 17:15
Mark Miller
2011-06-21, 17:32
johnmunir@...
2011-06-21, 18:01
Simon Willnauer
2011-06-21, 18:02
Robert Muir
2011-06-21, 18:16
Jan Høydahl
2011-06-21, 22:42
Copy link to this message
-
Re: Lucene 3.3 release soon?
DM Smith 2011-06-21, 18:33
On 06/21/2011 02:01 PM, [EMAIL PROTECTED] wrote:
>
> My bad, I meant to say a “6-8 releases a year” .. grrr!!
> So let me try this again. I don't like the current plan of "release
> early & often" because:
> 1) It will spread testing thin of any release because fewer real users
> will be using a release when you have too many a year.
I don't follow. With a release early and often rational, there will be
less changes in each release. Less to test. The testing of lucene is
phenomenal and improving with each release.

> 2) "release early & often" is not a well defined production release.
> It will lead to undefined gaps between releases (why X.Y took N weeks,
> but X.Z took M months?). This is why I suggested a quarterly release
> plan (it's what FF is now doing)
I think that the pendulum needs to swing and find its natural balance.
If there is a cost to frequent releases that is unacceptable, it will
all balance out in the end.
> 3) Do companies jump on a Lucene release as soon as one is made?  No,
> they have a process.  With too many releasees, they will now be more
> confused which releases to use; they want a release that proved itself.
I can't comment on how all companies do upgrades, but in my experience
the companies I've been with don't upgrade without a business reason.
Basically, if the current works then don't upgrade. If the new provides
a necessary feature for a specific requirement, then determine the
risk/cost/benefit and decide on whether to upgrade. But at the point of
upgrade go with the current best. I don't see how there would be
confusion until 4.0 is released.

In my specific application, upgrades to Lucene happen when my
application has a feature release and/or a bug release in it's use of
Lucene. It just doesn't make sense to have an app release that does not
give specific, visible benefit to end users.

> --MJ
>
>
> -----Original Message-----
> From: Mark Miller <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Sent: Tue, Jun 21, 2011 1:32 pm
> Subject: Re: Lucene 3.3 release soon?
>
> I think we might target fewer than 6-8 a month. That would be scary! I would
> guess it will be once a month at worse, and often less. Time will tell.
>
> You must already give version info with questions if you want decent help -
> nothing is going to change that.
>
> - Mark
>
>
> On Jun 21, 2011, at 1:15 PM,[EMAIL PROTECTED]  <mailto:[EMAIL PROTECTED]>  wrote:
>
> >  -1 on release early&  often.
> >
> >
> >  Let us say you average 6-8 releases a month, this means there will be that
> many versions used by users.  Which means the amount of testing done on a
> release (by real users, in real environment) will be spread thin thus a release
> will not get the same amount of testing it otherwise would.  Not only that, more
> releases means more releasespecific  questions.  Expect to see questions /
> issues reported and you must ask "what version are you using?" before you can
> answer.
> >
> >
> >  May I suggest a scheduled release, once a quarter, near the end of a quarter?
> >
> >
> >  -JM
> >
> >
> >  -----Original Message-----
> >  From: Simon Willnauer<[EMAIL PROTECTED]  <mailto:[EMAIL PROTECTED]>>
> >  To:[EMAIL PROTECTED]  <mailto:[EMAIL PROTECTED]>
> >  Sent: Tue, Jun 21, 2011 12:53 pm
> >  Subject: Re: Lucene 3.3 release soon?
> >
> >  On Tue, Jun 21, 2011 at 6:09 PM, Robert Muir<[EMAIL PROTECTED]  <mailto:[EMAIL PROTECTED]>
> >  >  wrote:
> >  >  Again, I don't think any future uncommitted features should block a
> >  >  release, nor should there be a "shoving" period where features are
> >  >  shoved in.
> >
> >  +1 - release early&  often!!!
> >
> >  simon
> >  >
> >  >  I'll be now looking at producing an RC as quickly as possible before
> >  >  this can happen!
> >  >
> >  >  On Tue, Jun 21, 2011 at 4:13 AM, Jan Høydahl<
> >  [EMAIL PROTECTED]  <mailto:[EMAIL PROTECTED]>
> >  >  wrote:
> >  >>  Grouping is really worth a release! But if group count in facet is within