Delete/deprecate HighlightingUtils?

[Mike Klaas <mi...@gmail.com>]

Core request handlers do not use this, favouring the new, almost- 
identical code in the highlighting package.  Deprecate or delete?  It  
is rather simple to upgrade code using this to the new regime.

-Mike

Re: Delete/deprecate HighlightingUtils?

[Chris Hostetter <ho...@fucit.org>]

: Since it is advanced not really public API stuff, it seems a bit cleaner to
: just delete.
: 
: Adding another to the TON of deprecated classes seems OK too...

if we want to follow hte precendent set by Lucene-Java, code that compiles 
against X.Y needs to be able to compile against X.Y+N ... so in theory 
if/when we delete any classes previously avaiable to people writing custom 
plugins, we have to bump the major version number.

i'm not sure we have to be such a stickler about it since the plugin 
writting community is a smaller subset of the total community (unlike 
lucene-java where the community of people compiling against the release is 
the entire community) but it would still be nice if there was at least one 
official release with a piece of deprecated before the first release where 
the code was completely removed.

...of course, now that we are actually starting to have our third 
release, and deprecate more code and remove older deprecated code we 
should probably write down what exactly our policy is.




-Hoss

Re: Delete/deprecate HighlightingUtils?

[Ryan McKinley <ry...@gmail.com>]

Mike Klaas wrote:
> Core request handlers do not use this, favouring the new, 
> almost-identical code in the highlighting package.  Deprecate or 
> delete?  It is rather simple to upgrade code using this to the new regime.
> 

Either way is fine by me.

Since it is advanced not really public API stuff, it seems a bit cleaner 
to just delete.

Adding another to the TON of deprecated classes seems OK too...