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. > 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. > > 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. Does that help, or have I further muddied the waters? Matthew -- Dr Matthew Pocock Visitor, School of Computing Science, Newcastle University mailto: [email protected] gchat: [email protected] msn: [email protected] irc.freenode.net: drdozer tel: (0191) 2566550 mob: +447535664143
