lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-1987) Remove rest of analysis deprecations (Token, CharacterCache)
Date Mon, 19 Oct 2009 11:45:31 GMT

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


Mime
View raw message