Re: branches/lucene_solr_4_0 and 4.0.1?
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
Re: branches/lucene_solr_4_0 and 4.0.1?
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
Re: branches/lucene_solr_4_0 and 4.0.1?
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
Re: branches/lucene_solr_4_0 and 4.0.1?
Initially, I started adding a 4.01 fix version to issues I thought should go in if we did 4.01 - but then I could not resolve those issues without back porting - which I didn't want to do in case we jumped to 4.1 or something - call me lazy :) So I started labeling until it became clear we would do a 4.01 - at which point I would change those labels to fix versions. I'm pretty sure we want a 4.01 at this point though. Mark Sent from my iPhone On Oct 17, 2012, at 7:13 PM, Chris Hostetter hossman_luc...@fucit.org wrote: I notice that the CHANGES.txt files on the lucene_solr_4_0 doesn't yet have a section for 4.0.1 bug fixes even though it looks like there have been some bug fix commits on that branch since 4.0.0 was released. On the other hand it looks like some folks (maybe just miller?) have been using the Jira label 4.0.1_Candidate on issues that get committed to the branch_4x, but aren't being commited to lucene_solr_4_0 -- presumably as a reminder that we should backport if we do a 4.0.1 release All of which leaves me a bit confused: is there any concensus on how we should be dealing with (potential) 4.0.1 bug fixes? -Hoss - 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
Re: branches/lucene_solr_4_0 and 4.0.1?
I've also only been porting to 4.1 so far (I'm assuming we'll release 4.1 soonish) but if we do a 4.0.1 I can re-visit ... Mike McCandless http://blog.mikemccandless.com On Thu, Oct 18, 2012 at 8:28 AM, Mark Miller markrmil...@gmail.com wrote: Initially, I started adding a 4.01 fix version to issues I thought should go in if we did 4.01 - but then I could not resolve those issues without back porting - which I didn't want to do in case we jumped to 4.1 or something - call me lazy :) So I started labeling until it became clear we would do a 4.01 - at which point I would change those labels to fix versions. I'm pretty sure we want a 4.01 at this point though. Mark Sent from my iPhone On Oct 17, 2012, at 7:13 PM, Chris Hostetter hossman_luc...@fucit.org wrote: I notice that the CHANGES.txt files on the lucene_solr_4_0 doesn't yet have a section for 4.0.1 bug fixes even though it looks like there have been some bug fix commits on that branch since 4.0.0 was released. On the other hand it looks like some folks (maybe just miller?) have been using the Jira label 4.0.1_Candidate on issues that get committed to the branch_4x, but aren't being commited to lucene_solr_4_0 -- presumably as a reminder that we should backport if we do a 4.0.1 release All of which leaves me a bit confused: is there any concensus on how we should be dealing with (potential) 4.0.1 bug fixes? -Hoss - 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
Re: branches/lucene_solr_4_0 and 4.0.1?
I suppose it depends. If people think we are on track for a 4.1 soon, perhaps we should skip 4.0.1 and just do a fairly fast 4.1. I think people would have to feel comfortable about some of the 4.1 changes - that nothing is that invasive. Otherwise it would probably be nice to do a bug fix only 4.0.1 for the cautious out there. Honestly, I could go either way. Any opinions? - Mark On Thu, Oct 18, 2012 at 8:32 AM, Michael McCandless luc...@mikemccandless.com wrote: I've also only been porting to 4.1 so far (I'm assuming we'll release 4.1 soonish) but if we do a 4.0.1 I can re-visit ... Mike McCandless http://blog.mikemccandless.com On Thu, Oct 18, 2012 at 8:28 AM, Mark Miller markrmil...@gmail.com wrote: Initially, I started adding a 4.01 fix version to issues I thought should go in if we did 4.01 - but then I could not resolve those issues without back porting - which I didn't want to do in case we jumped to 4.1 or something - call me lazy :) So I started labeling until it became clear we would do a 4.01 - at which point I would change those labels to fix versions. I'm pretty sure we want a 4.01 at this point though. Mark Sent from my iPhone On Oct 17, 2012, at 7:13 PM, Chris Hostetter hossman_luc...@fucit.org wrote: I notice that the CHANGES.txt files on the lucene_solr_4_0 doesn't yet have a section for 4.0.1 bug fixes even though it looks like there have been some bug fix commits on that branch since 4.0.0 was released. On the other hand it looks like some folks (maybe just miller?) have been using the Jira label 4.0.1_Candidate on issues that get committed to the branch_4x, but aren't being commited to lucene_solr_4_0 -- presumably as a reminder that we should backport if we do a 4.0.1 release All of which leaves me a bit confused: is there any concensus on how we should be dealing with (potential) 4.0.1 bug fixes? -Hoss - 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 -- - Mark - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: branches/lucene_solr_4_0 and 4.0.1?
On Thu, Oct 18, 2012 at 2:51 PM, Mark Miller markrmil...@gmail.com wrote: I suppose it depends. If people think we are on track for a 4.1 soon, perhaps we should skip 4.0.1 and just do a fairly fast 4.1. I think people would have to feel comfortable about some of the 4.1 changes - that nothing is that invasive. Otherwise it would probably be nice to do a bug fix only 4.0.1 for the cautious out there. Honestly, I could go either way. Any opinions? Personally I think a lucene 4.0.1 would be strange: on the other hand 4.1 is already looking very exciting. Just the fact we have a more efficient postings list format is really a huge change for lucene, as developers it might not seem that way since its just another codec but for users this is really a big deal and hasn't been done before. I think thats a big enough feature to justify a 4.1 release soonish (e.g. a month) myself. Not sure a 4.0.1 would come any faster: if there was a plan for such a thing I would want to backport all the bugfixes and so on from 4.1 where they are already safely integrated and baked... I think we should just plan on releasing more often. We should avoid massive massive releases like 4.0 in the future, there is just no need for that. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: branches/lucene_solr_4_0 and 4.0.1?
I don't think a 4.0.1 would be strange at all. 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. 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. It's also a signal to the community. You know you should upgrade to 4.0.1 and you know it will avoid unnecessary changes - just minimal, well thought out, bug fixes. With 4.1, many would just stay on 4.0 - they are not going to rock the boat for a feature release, but they would upgrade to a critical bug fix release. So I think it makes perfect sense. The only reason I don't push harder for it is the extra effort in releasing it along with 4.1. I see no reason to abandon bug fix releases though! I think they are very important. This is completely unrelated to how long it took to do 4.0. That release was long because there was a lot of pent up demand around non back compat refactoring. I'm not sure how that relates to whether or not we make a bug fix release. - Mark Personally I think a lucene 4.0.1 would be strange: on the other hand 4.1 is already looking very exciting. Just the fact we have a more efficient postings list format is really a huge change for lucene, as developers it might not seem that way since its just another codec but for users this is really a big deal and hasn't been done before. I think thats a big enough feature to justify a 4.1 release soonish (e.g. a month) myself. Not sure a 4.0.1 would come any faster: if there was a plan for such a thing I would want to backport all the bugfixes and so on from 4.1 where they are already safely integrated and baked... I think we should just plan on releasing more often. We should avoid massive massive releases like 4.0 in the future, there is just no need for that. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: branches/lucene_solr_4_0 and 4.0.1?
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
Re: branches/lucene_solr_4_0 and 4.0.1?
I think we should just add a CHANGES section for 4.0.1? There are 2 commits actually that Stefan made that should be moved under this section: I felt like i intended to do this (create 4.0.1 section and move them), but I think I forgot. In the past these branches (e.g. lucene_solr_3_6) have been setup with the assumption that there might be a 3.6.1... personally Ive been handling bugs by just committing them to 4.1. If someone said they wanted to do a 4.0.1, i would probably think about backporting some of these, but features etc are already starting to look nice for 4.1 so I havent worried myself yet. On Wed, Oct 17, 2012 at 4:13 PM, Chris Hostetter hossman_luc...@fucit.org wrote: I notice that the CHANGES.txt files on the lucene_solr_4_0 doesn't yet have a section for 4.0.1 bug fixes even though it looks like there have been some bug fix commits on that branch since 4.0.0 was released. On the other hand it looks like some folks (maybe just miller?) have been using the Jira label 4.0.1_Candidate on issues that get committed to the branch_4x, but aren't being commited to lucene_solr_4_0 -- presumably as a reminder that we should backport if we do a 4.0.1 release All of which leaves me a bit confused: is there any concensus on how we should be dealing with (potential) 4.0.1 bug fixes? -Hoss - 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
