Re: Lucene RC2
Depends on if changes supports trunk or releases I guess. I think it's dangerous to start down that line with trunk myself. It's one of the caveats trunk users endure - I don't consider them when I make changes in a dev cycle. It's the same way I'm not leaving deprecated methods for them. We have enough responsibilty with back compatible than to give trunk any priority over released versions IMO. A classic change file lists release changes - personally I think it's awkward to buck that convention and expose the dev history of a feature in a release changes. - Mark http://www.lucidimagination.com (mobile) On Sep 8, 2009, at 8:05 PM, Chris Hostetter wrote: : Thats how we have been attempting to handle it in Lucene - : update the previous issue with credits and merge the change : info. There are tricky situations - someone can get credit for : a huge issue when they just found a minor bug much later - : but that seems to fit in line with our generous credit model : anyway - if you really want to know, go to the JIRA issues. If : the same person found the bug and posted a patch before it : went in, they would be on the credit line anyway. If they find : it after release, they get a new bug fix credit. ... "eh" If a big feature is added, and then someone fins/fixes a small bug with it later, i dont' see anything wrong with having two enteries in the CHANGEs about this ... likewise if a feature is added and then a a bunch of extensions are made to it ... at a certain point if you keep collapsing things just because they are related you wind up with one long paragraph about how "lucene" changed between releases instead of a nice bulleted list. the big key i think is not having things that contradict ... if a bullet says we added XY&Z, but then a latter bullet says Z was removed and replaced with Q, we should just remove Z from the first bullet ... but that doesn't neccessarily mean Q needs to replace Z in that bullet .. Q can still be it's own bullet. -Hoss
Re: Lucene RC2
: Thats how we have been attempting to handle it in Lucene - : update the previous issue with credits and merge the change : info. There are tricky situations - someone can get credit for : a huge issue when they just found a minor bug much later - : but that seems to fit in line with our generous credit model : anyway - if you really want to know, go to the JIRA issues. If : the same person found the bug and posted a patch before it : went in, they would be on the credit line anyway. If they find : it after release, they get a new bug fix credit. ... "eh" If a big feature is added, and then someone fins/fixes a small bug with it later, i dont' see anything wrong with having two enteries in the CHANGEs about this ... likewise if a feature is added and then a a bunch of extensions are made to it ... at a certain point if you keep collapsing things just because they are related you wind up with one long paragraph about how "lucene" changed between releases instead of a nice bulleted list. the big key i think is not having things that contradict ... if a bullet says we added XY&Z, but then a latter bullet says Z was removed and replaced with Q, we should just remove Z from the first bullet ... but that doesn't neccessarily mean Q needs to replace Z in that bullet .. Q can still be it's own bullet. -Hoss
Re: Lucene RC2
> but that "update" doesn't need to be purely additive, it can be an >"edit" of an existing item in which case diffing the two versions of >CHANGES.txt will still tell you what you need to know. Thats how we have been attempting to handle it in Lucene - update the previous issue with credits and merge the change info. There are tricky situations - someone can get credit for a huge issue when they just found a minor bug much later - but that seems to fit in line with our generous credit model anyway - if you really want to know, go to the JIRA issues. If the same person found the bug and posted a patch before it went in, they would be on the credit line anyway. If they find it after release, they get a new bug fix credit. We could also just merge down at the end as part of release. Or kind of run the middle ground, or do nothing. First option makes the most sense to me though. - Mark Chris Hostetter wrote: > : think thats important. It just seems the Changes log should read what > : changed from 1.3 or else its a little confusing. You could make another > : argument with so many on trunk - but in my mind, the only thing those > : going from 1.3 to 1.4 should need to worry about is upgraded to 2.9 - > : not follow the whole dev path as changes invalidate changes. Not a big > > it's equally important that people experimenting with trunk/nightlys have > an easy way to distibguish what's changed between the version their using > and the current version, so CHANGES.txt should be updated for every change > -- but that "update" doesn't need to be purely additive, it can be an > "edit" of an existing item in which case diffing the two versions of > CHANGES.txt will still tell you what you need to know. > > > > -Hoss > > -- - Mark http://www.lucidimagination.com
Re: Lucene RC2
: think thats important. It just seems the Changes log should read what : changed from 1.3 or else its a little confusing. You could make another : argument with so many on trunk - but in my mind, the only thing those : going from 1.3 to 1.4 should need to worry about is upgraded to 2.9 - : not follow the whole dev path as changes invalidate changes. Not a big it's equally important that people experimenting with trunk/nightlys have an easy way to distibguish what's changed between the version their using and the current version, so CHANGES.txt should be updated for every change -- but that "update" doesn't need to be purely additive, it can be an "edit" of an existing item in which case diffing the two versions of CHANGES.txt will still tell you what you need to know. -Hoss
Re: Lucene RC2
+1 - I'm not against knowing what the last rev upgraded to was - I also think thats important. It just seems the Changes log should read what changed from 1.3 or else its a little confusing. You could make another argument with so many on trunk - but in my mind, the only thing those going from 1.3 to 1.4 should need to worry about is upgraded to 2.9 - not follow the whole dev path as changes invalidate changes. Not a big deal if I am the only one that thinks that, just a thought. If we didn't do it in general, it wouldn't matter if we didn't do with the Lucene upgrade though. - Mark Grant Ingersoll wrote: > It's very useful to know the rev # in a place that doesn't require: 1) > starting up Solr, 2) unpacking the Lucene jar, but yeah, we could just > have one entry at the top or something that just lists what the > current version and rev # are. > > On Sep 4, 2009, at 2:41 PM, Mark Miller wrote: > >> I keep sending emails from the wrong account: attempt 2: >> >> I think it's kind of weird how we add an entry every update - IMO it >> should be one entry- upgraded to Lucene 2.9. That's going to be the >> only change. >> >> - Mark >> >> http://www.lucidimagination.com (mobile) >> >> On Sep 4, 2009, at 12:03 PM, Grant Ingersoll >> wrote: >> >>> >>> On Aug 29, 2009, at 3:38 PM, Yonik Seeley wrote: >>> On Sat, Aug 29, 2009 at 5:44 PM, Bill Au wrote: > Yonik, >Are you in the process of trying it out or upgrading Solr, or > both? > Bill It's done: http://svn.apache.org/viewvc?view=rev&revision=809010 >>> >>> You should add a note to CHANGES.txt. > > -- - Mark http://www.lucidimagination.com
Re: Lucene RC2
It's very useful to know the rev # in a place that doesn't require: 1) starting up Solr, 2) unpacking the Lucene jar, but yeah, we could just have one entry at the top or something that just lists what the current version and rev # are. On Sep 4, 2009, at 2:41 PM, Mark Miller wrote: I keep sending emails from the wrong account: attempt 2: I think it's kind of weird how we add an entry every update - IMO it should be one entry- upgraded to Lucene 2.9. That's going to be the only change. - Mark http://www.lucidimagination.com (mobile) On Sep 4, 2009, at 12:03 PM, Grant Ingersoll wrote: On Aug 29, 2009, at 3:38 PM, Yonik Seeley wrote: On Sat, Aug 29, 2009 at 5:44 PM, Bill Au wrote: Yonik, Are you in the process of trying it out or upgrading Solr, or both? Bill It's done: http://svn.apache.org/viewvc?view=rev&revision=809010 You should add a note to CHANGES.txt.
Re: Lucene RC2
I keep sending emails from the wrong account: attempt 2: I think it's kind of weird how we add an entry every update - IMO it should be one entry- upgraded to Lucene 2.9. That's going to be the only change. - Mark http://www.lucidimagination.com (mobile) On Sep 4, 2009, at 12:03 PM, Grant Ingersoll wrote: On Aug 29, 2009, at 3:38 PM, Yonik Seeley wrote: On Sat, Aug 29, 2009 at 5:44 PM, Bill Au wrote: Yonik, Are you in the process of trying it out or upgrading Solr, or both? Bill It's done: http://svn.apache.org/viewvc?view=rev&revision=809010 You should add a note to CHANGES.txt.
Re: Lucene RC2
On Aug 29, 2009, at 3:38 PM, Yonik Seeley wrote: On Sat, Aug 29, 2009 at 5:44 PM, Bill Au wrote: Yonik, Are you in the process of trying it out or upgrading Solr, or both? Bill It's done: http://svn.apache.org/viewvc?view=rev&revision=809010 You should add a note to CHANGES.txt.
Re: Lucene RC2
On Sat, Aug 29, 2009 at 5:44 PM, Bill Au wrote: > Yonik, > Are you in the process of trying it out or upgrading Solr, or both? > Bill It's done: http://svn.apache.org/viewvc?view=rev&revision=809010 -Yonik http://www.lucidimagination.com
Re: Lucene RC2
Yonik, Are you in the process of trying it out or upgrading Solr, or both? Bill On Fri, Aug 28, 2009 at 3:32 PM, Yonik Seeley wrote: > On Fri, Aug 28, 2009 at 2:54 PM, Grant Ingersoll > wrote: > > Anyone tried out the new Lucene RC2 in Solr yet? Should we upgrade to > it? > > I'm in the process of doing so. > > -Yonik > http://www.lucidimagination.com >
Re: Lucene RC2
On Fri, Aug 28, 2009 at 2:54 PM, Grant Ingersoll wrote: > Anyone tried out the new Lucene RC2 in Solr yet? Should we upgrade to it? I'm in the process of doing so. -Yonik http://www.lucidimagination.com
Re: Lucene RC2
have not tried it yet but we should certainly upgrade. the more testing the better! On Aug 28, 2009, at 2:54 PM, Grant Ingersoll wrote: Anyone tried out the new Lucene RC2 in Solr yet? Should we upgrade to it?