commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <>
Subject Re: [codec] getting the bmpm code out there
Date Fri, 12 Aug 2011 18:57:12 GMT
On Thu, Aug 11, 2011 at 12:33 PM, sebb <> wrote:
> On 11 August 2011 19:38, Matthew Pocock <> wrote:
>> Hi,
>> As those of you who've been following the CODEC-125 ticket will know, with
>> Greg's help I've got a port of the beider morse phonetic
>> matching (bmpm) algorithm in as a string encoder. As far as I can tell, it's
>> ready for people to use and abuse. It ideally needs more test-case words,
>> but to the best of my knowledge it doesn't have any horrendous bugs or
>> performance issues.
>> The discussion on the ticket started to stray off bmpm and on to policy for
>> releases and changing APIs, and Sebb said we should discuss it on the list.
>> So, here we are.
>> Ideally, I'd like there to be a release of commons-codec some time soon so
>> that users can start to try out bmpm right away, and so that we can start
>> the process of adding it to the list of supported indexing methods in solr.
>> What do people think?
> The reason I raised the issue was that the API seems to be currently
> in a state of flux.
> Most Commons components strive for binary compatibility between releases.
> Where this cannot be achieved, normally this requires a change of
> package name and Maven id (as well as major version bump).
> This is to avoid the jar hell that can occur where two or more other
> pieces of code require different versions of the API, and where it's
> not possible to update all references to the changed code at once.
> In this case, because the BMPM code is new, it might be possible to
> relax the requirement somewhat, so long as the code API is documented
> as being unstable.
> If we do have to change BMPM in a way that is not binary compatible,
> then all code that uses the BMPM classes will need to be updated.
> This should be much less of an issue than if (say) the Base64 classes
> were changed, as there should not be many external classes that use
> BMPM in a given application.

My preference is to put unstable code in an unstable package name.

org.apache.commons.codec.unstable.encoders etc.

Very clear and we can later quite happily move it to the right package
name with a clear conscience.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message