You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-dev@lucene.apache.org by Grant Ingersoll <gs...@apache.org> on 2009/08/28 20:54:31 UTC
Lucene RC2
Anyone tried out the new Lucene RC2 in Solr yet? Should we upgrade to
it?
Re: Lucene RC2
Posted by Ryan McKinley <ry...@gmail.com>.
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?
Re: Lucene RC2
Posted by Mark Miller <ma...@gmail.com>.
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 <ho...@fucit.org>
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
Posted by Chris Hostetter <ho...@fucit.org>.
: 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
Posted by Mark Miller <ma...@gmail.com>.
> 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
Posted by Chris Hostetter <ho...@fucit.org>.
: 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
Posted by Mark Miller <ma...@gmail.com>.
+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 <gs...@apache.org>
>> wrote:
>>
>>>
>>> On Aug 29, 2009, at 3:38 PM, Yonik Seeley wrote:
>>>
>>>> On Sat, Aug 29, 2009 at 5:44 PM, Bill Au<bi...@gmail.com> 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
Posted by Grant Ingersoll <gs...@apache.org>.
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 <gs...@apache.org>
> wrote:
>
>>
>> On Aug 29, 2009, at 3:38 PM, Yonik Seeley wrote:
>>
>>> On Sat, Aug 29, 2009 at 5:44 PM, Bill Au<bi...@gmail.com> 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
Posted by Mark Miller <ma...@gmail.com>.
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 <gs...@apache.org>
wrote:
>
> On Aug 29, 2009, at 3:38 PM, Yonik Seeley wrote:
>
>> On Sat, Aug 29, 2009 at 5:44 PM, Bill Au<bi...@gmail.com> 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
Posted by Grant Ingersoll <gs...@apache.org>.
On Aug 29, 2009, at 3:38 PM, Yonik Seeley wrote:
> On Sat, Aug 29, 2009 at 5:44 PM, Bill Au<bi...@gmail.com> 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
Posted by Yonik Seeley <yo...@lucidimagination.com>.
On Sat, Aug 29, 2009 at 5:44 PM, Bill Au<bi...@gmail.com> 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
Posted by Bill Au <bi...@gmail.com>.
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 <yo...@lucidimagination.com>wrote:
> On Fri, Aug 28, 2009 at 2:54 PM, Grant Ingersoll<gs...@apache.org>
> 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
Posted by Yonik Seeley <yo...@lucidimagination.com>.
On Fri, Aug 28, 2009 at 2:54 PM, Grant Ingersoll<gs...@apache.org> 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