[ 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