I think an independent location for solrj changes is a good thing.
They are not relevant for anyone using any other client... the ruby
client has its own changelog. Solrj is a bit strange though since it
is used within the SearchComponents.
Since solrj has not yet been released, the coverage in CHANGES.txt it
a bit limited -- i don't think it is important for to follow all the
internal changes.
Re independent change log for DIH? that sounds good to me.
ryan
On Aug 14, 2008, at 4:27 PM, Shalin Shekhar Mangar wrote:
On a related note, I can see a CHANGES.txt inside client/java/solrj
folder.
However, it has not been updated with many changes that have took
place in
Solrj. I wasn't even aware of it's existence until recently.
Two options:
1. We merge it with the main changelog file and delete it
2. We gather all SolrJ changes from the main changelog and put it here
If we decide to go for the 2nd route, is a separate changelog needed
for DIH
as well?
On Sat, Aug 9, 2008 at 8:29 AM, Ryan McKinley <[EMAIL PROTECTED]>
wrote:
Hello-
Otis pointed out (via direct email) that I have not added many
notes in
CHANGES.txt recently. I may be getting slopy, but I also remember
some
discussion about how to use changes.txt a while back and figure we
should
revist it to make sure everything necessary is in there before 1.3.
My understanding is that CHANGES.txt is for folks following what has
happened between releases -- it does not need to include internal
modifications if there is no impact on the user.
For example, SOLR-493 is not there since it fixes an issue
introduced since
1.2 -- using CHANGES.txt to say what happened in SOLR-142 had some
side-effects that we now have cleared up seems overly complicated
for anyone
following. Likewise the recent changes/modifictions to the
UpdateRequestProcessor framework.
Is this understanding correct?
Are there more (or fewer) things we should include in CHANGES.txt?
ryan
--
Regards,
Shalin Shekhar Mangar.
