[ 
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

Reply via email to