There will be a balance over time. Perhaps we as a community need to prove that 
we can do frequent releases after such a long delay between 1.4.1 and 3.1 :) 
And by all means - we should. But whether it becomes 3.X.Y or 3.X+1 should be 
determined by whether it's some real new meat in there or mainly a bugfix 
release. If we release 3.3 with grouping and then find a major grouping bug a 
week later, we should be free to release 3.3.1 with bugfixes only, without 
needing to release any and all new stuff that happens to be committed to 3.x 
branch the last couple of days.

I'm not for super strict schedules, nor am I for randomly throwing out X.Y 
releases every month, confusing customers. Someone suggested in another thread 
to setup a preliminary loose roadmap with quarterly releases so that we all 
have some idea that we're all preparing for 3.X scheduled for, say, August-ish, 
and then 3.X+1 November-ish. I like that, and it won't stop us from adding or 
skipping a release if enough people feel that's justified. Also the idea of the 
RM sending out an email with a 1-2-week notice before the first RC is being 
produced, will let the community wrap things up. Of course this should never be 
an excuse for squeezing in immature code. The next train will come around soon 
enough anyway...

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com
Solr Training - www.solrtraining.com

On 21. juni 2011, at 20.33, DM Smith wrote:

> On 06/21/2011 02:01 PM, johnmu...@aol.com 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 <markrmil...@gmail.com>
>> To: dev@lucene.apache.org
>> Cc: simon.willna...@gmail.com
>> 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,johnmu...@aol.com  <mailto:johnmu...@aol.com>  
>> 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<simon.willna...@googlemail.com  
>> > <mailto:simon.willna...@googlemail.com>>
>> >  To:dev@lucene.apache.org  <mailto:dev@lucene.apache.org>
>> >  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<rcm...@gmail.com  
>> > <mailto:rcm...@gmail.com>
>> >  >  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<
>> >  j...@hoydahl.no  <mailto:j...@hoydahl.no>
>> >  >  wrote:
>> >  >>  Grouping is really worth a release! But if group count in facet is 
>> > within
>> >  reach, wait for that!
>> >  >>
>> >  >>  --
>> >  >>  Jan Høydahl, search solution architect
>> >  >>  Cominvent AS -
>> >  www.cominvent.com  <http://www.cominvent.com/>
>> >
>> >  >>  Solr Training -
>> >  www.solrtraining.com  <http://www.solrtraining.com/>
>> >
>> >  >>
>> >  >>  On 21. juni 2011, at 05.53, Bill Bell wrote:
>> >  >>
>> >  >>>  +1 wait for grouping post facet counts... Go Martijn v Groningen !!
>> >  >>>
>> >  >>>  On 6/20/11 12:03 PM, "Michael McCandless"<
>> >  luc...@mikemccandless.com  <mailto:luc...@mikemccandless.com>
>> >  >
>> >  >>>  wrote:
>> >  >>>
>> >  >>>>  +1 to releasing 3.3 in a few weeks... there's a lot of new stuff 
>> > after
>> >  >>>>  3.2.
>> >  >>>>
>> >  >>>>  Mike McCandless
>> >  >>>>
>> >  >>>>
>> >  http://blog.mikemccandless.com  <http://blog.mikemccandless.com/>
>> >
>> >  >>>>
>> >  >>>>  On Mon, Jun 20, 2011 at 7:36 AM, Robert Muir<
>> >  rcm...@gmail.com  <mailto:rcm...@gmail.com>
>> >  >  wrote:
>> >  >>>>>  i was planning on doing an RC in a few weeks actually.
>> >  >>>>>
>> >  >>>>>  we have a lot of good stuff in there today already, however i 
>> > wanted
>> >  >>>>>  to give a few weeks for the grouping stuff to run on hudson.
>> >  >>>>>
>> >  >>>>>  On Mon, Jun 20, 2011 at 4:59 AM, Simon Willnauer
>> >  >>>>>  <
>> >  simon.willna...@googlemail.com  <mailto:simon.willna...@googlemail.com>
>> >  >  wrote:
>> >  >>>>>>  I would say within the next 3 month.
>> >  >>>>>>
>> >  >>>>>>  Thoughts?
>> >  >>>>>>
>> >  >>>>>>  On Mon, Jun 20, 2011 at 10:56 AM, Lukáš Vlček<
>> >  lukas.vl...@gmail.com  <mailto:lukas.vl...@gmail.com>
>> >  >
>> >  >>>>>>  wrote:
>> >  >>>>>>>  Hi,
>> >  >>>>>>>  How soon can we expect official Lucene 3.3 release?
>> >  >>>>>>>  Best regards,
>> >  >>>>>>>  Lukas
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

Reply via email to