[
https://issues.apache.org/jira/browse/LUCENE-2226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12802004#action_12802004
]
DM Smith commented on LUCENE-2226:
----------------------------------
Robert, I'm suggesting that you move it. But that in CHANGES.txt that you make
it clear that part of the user's responsibility in upgrading is to delete the
snowball jar. I've been bit too many times by having both the old jar and a new
jar in the classpath. I know better but ....
I'd more or less agree with you that one could stay with old jars if it weren't
for bug fixes. Some bug fixes, such as in LUCENE-2055, will partially
invalidate an index, requiring it to be rebuilt to work as expected. I think
these need to be done and should not require bw compat maintenance of the bug.
Mark, that is my understanding too. I wasn't commenting on the policy but on
the fact of the possible breakage. I think it is a courtesy to notify users of
a change to which they might need to pay attention. I don't know that's spelled
out in the policy, but I think it should be. Not that a lack of notice is a
guarantee of no breakage but that a notice is a guarantee of breakage (at least
under some circumstances).
Is there any contrib that specifically states one? I couldn't find it. That
said, the last release went to great lengths to preserve bw compat in some
contribs, especially contrib/analyzers/common. This is attested to by the
Version attribute. Is that the implicit statement of the policy? It is clear
that Snowball has broken backward compatibility in the past. I presume it will
in the future. The smartcn package is marked experimental. The analysis/common
is not clear as it has the Version stuff.
Part of what Robert is saying (or at least what I am hearing): Snowball should
be trusted, but contrib/common stemmers should not. If the latter had an
implicit bw compat policy (in view of the Version usage), does that indicate
that Snowball should inherit the bw compat? (I'm being a bit argumentative, I
know. ATM, I don't think it is that important. But after all the dust settles
and this i18n stuff is solid, I think it might be reasonable to make a stronger
bw compat statement.)
Regarding the policy, I think it is good and give users confidence in the
stability of Lucene and the longevity of their indexes. As I see it, the bw
compat policy covers English well, western European ok, but other languages
poorly. Other than English it is likely that one is using a contrib to do
analysis. I think that ultimately it will be important for bw compat to cover
non-English well. I might be wrong here, any large project is likely to index
non-English texts and will need index level compatibility. Right now the only
option is to use contrib as a copy source.
As I see it the bw compat policy covers several things:
1) index compatibilty across 2 major releases.
2) api compatibility within 1 major release.
3) drop in jar compatibility from one release to the next. Going to a x.0
release requires deprecations to be addressed.
I think these are in the order that I care about them. WRT 2), I really only
care about semantic changes. As long as there is a good mechanism to identify
what I need to do, I really don't care that the call interface changes when
there is semantic equivalence.
WRT 3) I don't care at all.
And regarding 1), I'd rather have correctness and have bugs fixed, causing a bw
break than preserve a "bad" index.
But that's just me. Just one.....
> move contrib/snowball to contrib/analyzers
> ------------------------------------------
>
> Key: LUCENE-2226
> URL: https://issues.apache.org/jira/browse/LUCENE-2226
> Project: Lucene - Java
> Issue Type: Task
> Components: contrib/analyzers
> Reporter: Robert Muir
> Assignee: Robert Muir
> Fix For: 3.1
>
> Attachments: LUCENE-2226.patch
>
>
> to fix bugs in some duplicate, handcoded impls of these stemmers (nl, fr, ru,
> etc) we should simply merge snowball and analyzers, and replace the buggy
> impls with the proper snowball stemfilters.
--
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
