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

Michael McCandless commented on LUCENE-1678:
--------------------------------------------


bq. Mike was gung ho for it for a while, and even he backed off. 

Well... my particular itch (most recently!) was an addition to Lucene
that'd let us conditionalize the default settings so that new users
get the latest & greatest, but back-compat users can easily preserve
old behavior.

Ie, it was a software change, not a policy change; I tried hard to
steer clear of any proposed changes to back-compat policy.

But, for better or worse, back-compat policy is one of those
"magnetic" topics: whenever you get too close to it, it suddenly
sticks to you and takes over your thread.

And in the end we arrived at a workable solution to my particular
itch, which is to make such settings explicit or switch to new APIs
that change the defaults (eg the new FSDir.open).

That said, improving our back compat policy *is* an important and
amazingly complex topic.


> 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