[
https://issues.apache.org/jira/browse/SOLR-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12802614#action_12802614
]
Mark Miller commented on SOLR-1677:
-----------------------------------
If you are thinking of VERSION as alternate versions, I can see your point.
But I can't imagine thats what VERSION is for.
{quote} everyone else seems to have a very fixed view that these Version based
changes are genuine improvements/bug-fixes, w/o any expectation that clients
might/could subjective decide "i want the old behavior" and that older
"Versions" are supported purely for back-compatibility. {quote}
I don't think Versions is meant to be used so that users can choose how things
operate - personally I do see it as purely a way to get bad behavior for back
compatibility. If thats not the case, we should not use Version in Lucene, we
should make a Class2. Then you pick which you want. To me, Version is for
fixing bugs or things that are clearly not the right way of doing things. Not a
choice list. If more than one choice makes sense that should be done without
Version. Personally thats all that makes sense to me. Perhaps it will be
abused, but personally I'd push back. Version is not a functionality selector -
its a way to handle back compat for bugs and clear improvements - stuff we plan
and hope to drop into a big black hole forever. Not "options" that make sense
and we plan to keep around for users to mull over.
I'm also not that worried that users won't know what changed - they will just
know that they are in the same boat as those downloading Lucene latest greatest
for the first time. Likely the best boat to be in when it comes to this stuff.
If they want to manage things piece mail, I'm still all for allowing Version
per component for experts use. But man, I wouldn't want to be in the boat,
managing all my components as they mimic various bugs/bad behavior for various
components.
When I download the latest Solr and do a fresh install, I want it to have all
of the latest Lucene bugs fixed (not the case currently). When I have an old
install, I want to be able to change one setting and reindex to get all known
bugs fixed (currently not the case - heck its not even possible to run Solr
currently with all the known Lucene bugs fixed).
> Add support for o.a.lucene.util.Version for BaseTokenizerFactory and
> BaseTokenFilterFactory
> -------------------------------------------------------------------------------------------
>
> Key: SOLR-1677
> URL: https://issues.apache.org/jira/browse/SOLR-1677
> Project: Solr
> Issue Type: Sub-task
> Components: Schema and Analysis
> Reporter: Uwe Schindler
> Attachments: SOLR-1677.patch, SOLR-1677.patch, SOLR-1677.patch,
> SOLR-1677.patch
>
>
> Since Lucene 2.9, a lot of analyzers use a Version constant to keep backwards
> compatibility with old indexes created using older versions of Lucene. The
> most important example is StandardTokenizer, which changed its behaviour with
> posIncr and incorrect host token types in 2.4 and also in 2.9.
> In Lucene 3.0 this matchVersion ctor parameter is mandatory and in 3.1, with
> much more Unicode support, almost every Tokenizer/TokenFilter needs this
> Version parameter. In 2.9, the deprecated old ctors without Version take
> LUCENE_24 as default to mimic the old behaviour, e.g. in StandardTokenizer.
> This patch adds basic support for the Lucene Version property to the base
> factories. Subclasses then can use the luceneMatchVersion decoded enum (in
> 3.0) / Parameter (in 2.9) for constructing Tokenstreams. The code currently
> contains a helper map to decode the version strings, but in 3.0 is can be
> replaced by Version.valueOf(String), as the Version is a subclass of Java5
> enums. The default value is Version.LUCENE_24 (as this is the default for the
> no-version ctors in Lucene).
> This patch also removes unneeded conversions to CharArraySet from
> StopFilterFactory (now done by Lucene since 2.9). The generics are also fixed
> to match Lucene 3.0.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
