I'd say two things: there are def some bad bugs already that would warrant a 4.01.
I'd push for 4.1 well before jan. - Mark Sent from my iPhone On Oct 19, 2012, at 6:57 AM, Erick Erickson <erickerick...@gmail.com> wrote: > Personally, I suspect that enough people are going to hop on the 4.0 > code that _something_ will come bubbling up out of the cracks that > needs to be addressed. I mean there's a lot that's in that release, plus > things that people are geeked to try. Not necessarily killer bugs, more > like enhancements. > > So I'm rather expecting a relatively quick turn-around for 4.1 and wouldn't > push for a 4.0.1 unless and until there's a killer bug. Which, as Robert > says, there aren't any examples of in the CHANGES file yet, so no reason > for a 4.0.1. > > I'll throw out a straw-man proposal of targeting January for 4.1. Not a hard > date, more a proposal for taking stock after the Holidays and seeing what > we think. > > Besides, even though I don't hava a hand in it, is such a pain, especially > for people who'd rather be coding.... > > Erick > > On Thu, Oct 18, 2012 at 7:58 PM, Robert Muir <rcm...@gmail.com> wrote: >> On Thu, Oct 18, 2012 at 4:53 PM, Mark Miller <markrmil...@gmail.com> wrote: >>> I don't think a 4.0.1 would be strange at all. >> >> I just think it would be strange since there aren't really any serious >> bugs yet in the lucene CHANGES.txt? I also don't think there has been >> enough time for anyone to actually find any bugs, its only been like 6 >> days since we released. >> >>> >>> 4.X is essentially trunk to me now. I would put in changes that I want >>> to bake for future 4.1, 4.2, 4.3, etc changes. >> >> Sure, well there aren't many architectural changes yet since 4.0, and >> currently we have the ability to make and bake large changes to lucene >> in many cases (block postings format, compressed stored fields, etc) >> without introducing risk, since they are just experimental until we >> decide to fold them into the default. >> >> But personally as soon I hit some limit in the codec API (which I >> expect will happen), or want to work on something biggish like >> positions iterators, I'll be looking at doing that kind of breaking >> change only in trunk. >> >> I just think we shouldn't hold back from that: we should develop in a >> correct and safe way and not backport scary stuff or majorly break >> APIs to get them out faster, instead 4.x should stay stable and we >> should plan on 5.x being in our own lifetimes. >> >> i dont want there to be the assumption that 5.0 is 3 years out. >> >>> >>> When you have bad bugs, you don't want to worry about what's baking - >>> you just want to put out a bug fix release. >> >> I totally agree with this! But I have serious concerns about the >> ability for this community to say "hey we fixed some nasty shit, lets >> get a bugfix out ASAP". Nobody is really testing until release >> candidates are issued, the 72-hour voting period designed to be fair >> to devs in different timezones is bastardized as some iterative QA >> cycle, etc etc. >> >> So if we are going to go thru all the trouble, I'd rather it be a 4.1 >> >> --------------------------------------------------------------------- >> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
