[
https://issues.apache.org/jira/browse/LUCENE-1678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12718081#action_12718081
]
Michael McCandless commented on LUCENE-1678:
--------------------------------------------
bq. Adopting a fixed release cycle with small intervals between releases
(compared to what we have now).
I think this is almost a good solution, though instead of "fixed" it
could be that we try [harder] to do major releases more frequently.
Let's face it: Lucene is changing quite quickly now, so it seems
reasonable that the major releases also come quickly.
I say "almost" because.... alot of the pain in implementing our
current policy is the need to have a "stepping stone" between old and
new. Ie, we now must always do a release that deprecates old APIs and
introduces new ones so that you can upgrade to that, fix deprecations,
and you know you're set for the next major release. So eg changes to
interfaces is a big problem. If we were free to suddenly make a new
major releases, with instructions on how to migrate old -> new, that'd
be very liberating.
I think nearly everyone agrees our back-compat policy is exceptionally
costly. On a given interesting change to Lucene, a very large part of
the effort is spent on preserving back-compat. It causes all kinds of
spooky code, pollutes the APIs, causes us to go forward with sub-par
names, etc. The freedom Marvin has to make changes to Lucy is
fabulous, though in exchange, it's not yet released...
I think most would also agree that it's far from easy even carrying
out the policy we have without making mistakes: this change (addition
of reusableTokenStream) violated our policy (I did it by accident and
nobody noticed until now). I actually believe programming languages /
runtime envs need to provide more support for developers; we have
inadequate tools now. But we can't wait for that...
> 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
