On 11 August 2011 20:55, Matthew Pocock <turingatemyhams...@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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
