When I think of CHANGES.txt, I think of communicating to users. We
write something succinct for the benefit of users to understand how
this change will impact them.
I don't think of CHANGES.txt as a log of all changes. I think
increasing the scope to such wastes the time of users (and *we* are
also users!), and dilutes the value of more meaningful entries.
I know we have an "Other" section... perhaps this section allows us to
add stuff that no user ought to care about. Not sure if users know to
not waste their time looking at it. Still... I think we shouldn't
bother adding some changes to CHANGES.txt at all.
So... if a deprecated method is replaced with an equivalent... lets
just not add this; okay? Specific example: replacing new URL("...")
with the new equivalent. Honestly I don't even need to ask; just
don't. Perhaps others have input on other examples or have different
perspectives of thinking about this. The presence of a JIRA issue
doesn't necessarily mean a CHANGES.txt entry needs to be added.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
For additional commands, e-mail: dev-h...@solr.apache.org
