On Tue, Oct 23, 2012 at 2:10 PM, Mark Miller <markrmil...@gmail.com> wrote: > 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.
+1 I'd add that just because there hasn't been a lot of time to find additional bugs in 4.0 doesn't mean that we should artificially delay a 4.0.1. If/when more bugs are found after that, we can always do a 4.0.2 (if 4.1 still isn't imminent). -Yonik http://lucidworks.com > - 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
