[
https://issues.apache.org/jira/browse/LUCENE-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12767299#action_12767299
]
Michael McCandless commented on LUCENE-1987:
--------------------------------------------
bq. I did not remove the other version constants, because then we have them and
can use them anywhere else. And a user coming from e.g. 2.2 to 3.0 can just use
LUCENE_22 to match his old behaviour. The user should be free to give his
version he used before for this backwards compatibility.
OK I think that's reasonable.
bq. Mike: Should I backport the setting for 2.4 to 2.9 to enable
plugin-replacements from 2.9.1 to 3.0?
+1
{quote}
bq. Going forward, when we fix a bug but need to conditionally preserve the bug
for back compat, we should use the version switching so that by default for new
users (VERSION_CURRENT or VERSION_XX if XX is the next release) the bug is
fixed.
Do you mean I should add the default ctor of StandardAnalyzer() and rewire it
to LUCENE_CURRENT?
{quote}
Sorry, I wasn't clear...
No -- I don't think we should ever have a ctor that defaults to LUCENE_CURRENT.
That's a back compat trap (and it just gets us back to where we started when
we had no explicit version). Users must be explicit about which version they
want.
What I meant was: when fixing some sneaky bug in the future, we should never
set the default so that the bug is still present (as we did on the first go of
"invalid acronyms"), expecting new users to realize they have to go out of
their way to tell Lucene not to emulate the bug. Instead, the default going
forward (if version >= next-release-version) should be "the bug is fixed".
> Remove rest of analysis deprecations (Token, CharacterCache)
> ------------------------------------------------------------
>
> Key: LUCENE-1987
> URL: https://issues.apache.org/jira/browse/LUCENE-1987
> Project: Lucene - Java
> Issue Type: Task
> Components: Analysis
> Reporter: Uwe Schindler
> Assignee: Uwe Schindler
> Fix For: 3.0
>
> Attachments: LUCENE-1987-StopFilter.patch,
> LUCENE-1987-StopFilter.patch, LUCENE-1987-StopFilter.patch,
> LUCENE-1987.patch, LUCENE-1987.patch, LUCENE-1987.patch
>
>
> These removes the rest of the deprecations in the analysis package:
> - -Token's termText field-- (DONE)
> - -eventually un-deprecate ctors of Token taking Strings (they are still
> useful) -> if yes remove deprec in 2.9.1- (DONE)
> - -remove CharacterCache and use Character.valueOf() from Java5- (DONE)
> - Stopwords lists
> - Remove the backwards settings from analyzers (acronym, posIncr,...). They
> are deprecated, but we still have the VERSION constants. Do not know, how to
> proceed. Keep the settings alive for index compatibility? Or remove it
> together with the version constants (which were undeprecated).
--
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
