lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Earwin Burrfoot (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-1678) Deprecate Analyzer.tokenStream
Date Tue, 09 Jun 2009 23:19:07 GMT

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

Earwin Burrfoot commented on LUCENE-1678:
-----------------------------------------

bq. If there are sane/smart ways to change our back compat policy, I think you have seen that
no one would object.
It's not a matter of finding a smart way. It is a matter of sacrifice that has to be made
and readiness to take the blame for decision that can be unpopular with someone.
You go zealously for back-compat - you sacrifice readability/maintainability of your code
but free users from any troubles when they want to 'simply upgrade'. You adopt more relaxed
policy - you sacrifice users' time, but in return you gain cleaner codebase and new stuff
can be written and used faster.
There's no way to ride two horses at once.

Some people are comfortable with current policies. Few cringe when they hear things like above.
Most theoretically want to relax the rules. Nobody's ready to give up something for it.

Okay, there's an escape hatch I (and someone else) mentioned on the list before. Adopting
a fixed release cycle with small intervals between releases (compared to what we have now).
Fixed - as in, releases are made each N months instead of when everyone feels they finished
and polished up all their pet projects and there's nothing else exciting to do. That way we
can keep the current policy, but deletion-through-deprecation approach will work, at last!
This solution is halfassed, I can already see discussions like "That was a big change, let's
keep the deprecates around longer, say - for a couple of releases.", it doesn't solve good-name-thrashing
problem, as you have to go through two rounds of deprecation to change semantics on something,
but keep the name.
But this is something better than what we have now, a-a-and this is something that needs commiter
backing.

bq. Thats a great indication to me that the issue is not simple.
The issue is simple, the choice is not. And maintaining status quo is free.

bq. Giving up is really not the answer though
It is the answer. I have no moral right to hammer my ideals into heads that did tremendously
more for the project, than I did. And maintaining a patch queue over Lucene trunk is not 'that'
hard.


> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message