John, all, On Thu, Dec 31, 2015 at 12:21 PM, John M <john.wilkinson...@gmail.com> wrote: > Is the approach of adding new API and deprecate the old sound acceptable? Or > are public API changes acceptable?
In general I think keeping APIs is a good thing, also for development branches. I think APIs should be kept, unless there is a good reason to change them. However, I also think that our APIs should not be carved in stone; we've not spent months or even weeks on designing APIs and just do things wrongly, I think. It does give us a strong responsibility to inform people about changes, of course, and I have tried to do my bits in my blog in this respect (as well as a chapter in my book). However, there is one API change I want to single out, which I strongly feel about, because I consider them bug fixing: the use of implementations instead of interfaces of the core APIs (Atom versus IAtom, etc). In the past we have found that one implementation does not suffice, I think we will face this again. In general, we made the mistake to write APIs based on implementation, which is the bug here. Fixing this was started some years ago and I like to finish this. It has uncovered quite a few bugs in implementations of the interfaces and wrong assumptions of various kinds. That strengthens me that this is of quite a different level of API changes. Furthermore, they are special in a second way: ChemFile implements IChemFile (etc). That means that downstream code will only break when that code was using APIs from ChemFile that was not specified in the interfaces. That should probably not even exist and there is a minimum amount of that anyways. So, to me, there are different API changes, once that I think should not happen, and those that must happen. The latter, in a development branch, I think is appropriate. For the other, we have seen various ways for overcoming this: 1. add new classes with the new API versions and deprecated the old ones [I like that] 2. add new methods with the new API versions and deprecated the old ones [I like that; that does not always solve the issue] A final thought is that keeping old APIs (deprecated code) also means more code to maintain; with the restricted amount of resources, I am not sure to what extend we can or should do that. Instead, I rather (or also) focus on making a better effort in educating the community (that includes myself, because I have a lot of your new APIs to learn!!) in new APIs and old ones not to use anymore. Also, I really love to have a better overview of API versions (read: CDK versions) downstream tools are using. Egon -- E.L. Willighagen Department of Bioinformatics - BiGCaT Maastricht University (http://www.bigcat.unimaas.nl/) Homepage: http://egonw.github.com/ LinkedIn: http://se.linkedin.com/in/egonw Blog: http://chem-bla-ics.blogspot.com/ PubList: http://www.citeulike.org/user/egonw/tag/papers ORCID: 0000-0001-7542-0286 ImpactStory: https://impactstory.org/EgonWillighagen ------------------------------------------------------------------------------ _______________________________________________ Cdk-user mailing list Cdk-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdk-user
