On 7/9/07, Chris Hostetter <[EMAIL PROTECTED]> wrote:
: http://www.nabble.com/Re%3A-Tika-Changelog-p11082404.html
:
: IMO, changes in implementation detail don't belong in CHANGES.txt,
: unless it's to give credit to a contributor for that change (which
: committers don't need).
:
: For example, the following change shouldn't matter to normal users:
: SOLR-262: Added toObject( Fieldable ) to FieldType. [...]
i agree with teh sentiments you posted to the tika list, but we have to
keep in mind that the scope of "users" is broad ... that note about
SOLR-262 may not be important to users that only deal with Solr out of the
box, but it is important to advanced users writing their own plugins --
and should be noted in teh CHANGES.txt somewhere
I disagree that it needs to be in CHANGES.txt... advanced expert users
will also use the source/javadoc (and creating ones own field types is
definitely advanced). Every public class and method in solr isn't
equally part of the "public" API.
It's somewhat subjective, but if we changed the semantics of something
like IndexSearcher.getDocList(), that should definitely be in
CHANGES.txt
If we added a more obscure method that didn't exist before (like
getFirstMatch()), that wouldn't need to be added (it's noise to most
users, doesn't change existing functionality, not accessible w/o
writing Java code, and an advanced user can pull up the javadoc).
... but i would agree
that the "New Features" section probably isn't the right place for it.
Yes, either "other" or a new "java API" section
-Yonik
