[ 
https://issues.apache.org/jira/browse/LUCENE-1678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12718122#action_12718122
 ] 

Shai Erera commented on LUCENE-1678:
------------------------------------

We've had this thread 
http://www.nabble.com/Lucene%27s-default-settings---back-compatibility-td23605466.html,
 and in the latest post 
(http://www.nabble.com/Re%3A-Lucene%27s-default-settings---back-compatibility-p23792927.html)
 I tried to put together some wording for a revised (and relaxed) back-compat 
policy. I believe it was Grant who asked for some writeup to get to the users' 
list, and I read also that we may want to discuss each item separately, to get 
to a consensus.

Perhaps we can continue the discussion on that thread, and try to get to a 
consensus on any of the items? We don't necessarily need to change all of it in 
one day, but getting some feedback from you on any of the items can help bring 
that discussion back to life, and hopefully reach a consensus.

As was said on this thread, persistence will eventually drive us to reach a 
consensus, so I'm being persistent :).

> Deprecate Analyzer.tokenStream
> ------------------------------
>
>                 Key: LUCENE-1678
>                 URL: https://issues.apache.org/jira/browse/LUCENE-1678
>             Project: Lucene - Java
>          Issue Type: Bug
>          Components: Analysis
>            Reporter: Michael McCandless
>            Assignee: Michael McCandless
>            Priority: Minor
>             Fix For: 2.9
>
>
> The addition of reusableTokenStream to the core analyzers unfortunately broke 
> back compat of external subclasses:
>     
> http://www.nabble.com/Extending-StandardAnalyzer-considered-harmful-td23863822.html
> On upgrading, such subclasses would silently not be used anymore, since 
> Lucene's indexing invokes reusableTokenStream.
> I think we should should at least deprecate Analyzer.tokenStream, today, so 
> that users see deprecation warnings if their classes override this method.  
> But going forward when we want to change the API of core classes that are 
> extended, I think we have to  introduce entirely new classes, to keep back 
> compatibility.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

Reply via email to