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