[
https://issues.apache.org/jira/browse/LUCENE-2396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12857487#action_12857487
]
DM Smith commented on LUCENE-2396:
----------------------------------
bq. Well, I think asking for a well-defined backwards compatibility policy for
'all analyzers' is asking too much. Things are not so simple and sorted out
like they are with English/porter stemming, etc.
Some ramblings:
I think things need to change/improve wrt analyzers, tokenizers and filters.
The current Version mechanism is a road block. So is bw compat. I get that.
When I asked for a well-define compatibility policy, I was not suggesting that
we go back to the old mechanism or keep the new Version mechanism. Just a clear
statement on what the policy is. It might be on a per class basis.
One mechanism that would work is versioned Java package names or class names.
The current release would get the good names. If a user wanted the old jar
they'd have to get it from the current release (e.g.
lucene-analyzers-3.5_3.0.jar) and then change their code to use the old stuff
which now has either a new package name or a new class name. Example,
trStemmer.java is going to be changed as the first breaking change since 3.0,
so trStemmer3_0.java is created as a copy and then trStemmer.java is changed.
The compatibility policy would be that the jar is not a drop in replacement,
but that the old classes still exist, albeit with a different name.
I have worked on some contributions w/ bw compat and it is a pain. I didn't
like it. And that was both pre-version and post-version. I'd like to see
version go away, but I'm not sure I'd like bw compat to go away. As it is I'm
resigning myself that as I use each release of Lucene, I'm going to want more
from it and that is likely to require index rebuilds. Right now I'm stuck with
the 2.9 series and what happens until I upgrade to 3.x or 4.x doesn't really
impact me. It will impact me then. I'll figure out how to deal with it and suck
it up.
Some other things I'd like to see:
* I'd like to see fully controllable Unicode support. The only way I see this
is if we use ICU. It will take the java version problem out of the picture. A
user would have control of the version of Unicode by their control of the
version of ICU.
* An analyzer construction factory, that would take a spec (of fields,
tokenizers, stop words, stemmers, ....) and spit out an per field analyzer.
This would allow for the deprecation of the analyzers.
These and others would be more readily tackled if the bw compat policy did not
get in the way.
bq. I'll go with the flow, we can stay with what we have now, and the language
support will also likely remain weak like it is now.
You know I don't want that ;)
I was suggesting that this issue should wait to see what the outcome of the
general Version discussion is. Even if it is negative, perhaps this can go
forward.
bq.Currently I feel its an immense up-front effort to contribute any analysis
support, it has to be near-perfect less it will cause future problems, because
its not easy to iterate with the current situation without creating a mess.
With new stuff, even in core, if it is marked as experimental, it is outside
the bw compat policy. That gives the opportunity to iterate. Dev branches are
another good way.
But please, keep up the good work!
> remove version from contrib/analyzers.
> --------------------------------------
>
> Key: LUCENE-2396
> URL: https://issues.apache.org/jira/browse/LUCENE-2396
> Project: Lucene - Java
> Issue Type: Task
> Components: contrib/analyzers
> Affects Versions: 3.1
> Reporter: Robert Muir
> Assignee: Robert Muir
> Attachments: LUCENE-2396.patch
>
>
> Contrib/analyzers has no backwards-compatibility policy, so let's remove
> Version so the API is consumable.
> if you think we shouldn't do this, then instead explicitly state and vote on
> what the backwards compatibility policy for contrib/analyzers should be
> instead, or move it all to core.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
