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
