commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [codec] getting the bmpm code out there
Date Thu, 11 Aug 2011 20:38:27 GMT
On 11 August 2011 20:55, Matthew Pocock <turingatemyhamster@gmail.com> wrote:
> Hi Sebb,
>
>
>> The reason I raised the issue was that the API seems to be currently
>> in a state of flux.
>>
>
> The BMPM code has not appeared in a previous release. It is a discrete
> addition that doesn't alter any existing code, and as far as I know,
> currently no 3rd party code relies upon it. Right now on trunk, it is a
> StringEncoder.

OK

>
>> 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.
>>
>
> I've no problem with marking it as new or unstable or whatever the right
> word is. While it extends StringEncoder, the API is stable. Although there
> may be more flux with the finer details of the string you get out for the
> string you put in as we fix bugs and update the rule tables, this shouldn't
> alter how clients (users of the API) call this code, only the quality of the
> results they get back.

OK, that won't affect binary compat.

>
>>
>> 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.
>>
>
> Understood. I think this only becomes an issue if/when Encoder becomes
> generified, and at that point clearly we need a big version bump, with all
> the associated changes, and all encoders and their clients would be equally
> affected.

Indeed.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message