[
https://issues.apache.org/jira/browse/LUCENE-2226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12802011#action_12802011
]
Mark Miller commented on LUCENE-2226:
-------------------------------------
{quote}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).{quote}
Right - I was just pointing out that jar drop in is far from a requirement in
contrib. We do always try and play nice anyway.
bq. Is there any contrib that specifically states one? I couldn't find it.
Don't think so - meaning there is no back compat policy in contrib - I think as
a contrib matures, its up to those working on it to decide that its reached a
state that deserves a policy of some kind. The Highlighter could probably use
one at this point, but at the same time, nothing has created too much of an
outcry at this point.
bq. The analysis/common is not clear as it has the Version stuff.
Right - just because there is no policy doesn't mean we shouldn't make any
attempts at back compat - but the issue you brought up is not something easily
addressed, nor I think, large enough to worry about with the proper warning in
Changes. Users should be wary of contrib on upgrading - unless it presents a
strong back compat policy.
bq. 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.
I agree - now that contrib has been getting some much needed love recently, I
think it should start heading towards some back compat promises - especially
concerning analyzers. We already do tend to bend over backwards when we can
anyway.
I think we are on the same page - I'm just not very worried about the break you
mention - I think its a perfectly acceptable growing pain. And I think our back
compat has been so week because contrib has been a bit of a wasteland in the
past - no one was willing to take ownership of a lot of this stuff - especially
the language analyzers. That has change recently. As the devs clean up and
consolidate this stuff properly, I think we can work towards stronger promises
in the future.
> 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
