From: Egon W. <ego...@gm...> - 2008-08-08 09:12:48
|
Hi all, people are requesting a new CDK release, and early May Rajarshi hinted at the possibility of making a new stable release, and here's an update. (A summary is down the email) On Fri, May 2, 2008 at 7:25 AM, Egon Willighagen <ego...@gm...> wrote: > as Rajarshi suggested on the user mailing list, it is time to start > making official releases based on trunk. > > This should really go into the wiki, but I see these todo's for CDK > 1.2, with a 1.1 developers series... Still nothing in the wiki. > - add missing elements to atom type perception code There are more atom types defined now, at least equal to the number we have in CDK 1.0, but I'll work on this a bit more. > - clean up JChemPaint code Code mostly cleaned up. CDK 1.2.0 will *not* have a JChemPaint based on it. > - finish converting all JUnit3 tests to JUnit4 tests Still a lot of code to convert, I think. We need some statistics on this... > - split up algorithms from QSAR descriptors wrappers > - put atomic/bond descriptors still on qsarmolecular back in qsaratomic/qsarbond Mostly done. Not a blocker any more. qsaratomic, qsarbond, and qsarmolecular are now no longer showing interdependencies, and that was the goal. > - verify versions and update libraries we depend on There is a patch in the works to remove dependency on JGraphT, but this is postponed to 1.3. > Along with the regular stuff we do: > > - define the stable code, and make it stable > - fix JavaDocs > - clean up PMD warnings > - fix bug causing failing unit tests (way too many at this moment) Work on this has been done, but in particular the first is to be done asap. I recently cleaned up depedencies, which allows us define a nice clean set of 'stable' core functionality. After the iterable patch is applied, I'll 'freeze' CDK 1.1 and we'll move into bug fix mode. > And this is modules which are broken or with unsure status otherwise: > > - builder3 > > fingerprints for ring structure db needs fixing Seems to break every now and then, when fixes in the atom typing are applied :( This is a serious problem... I think the fingerprinter used for the builder3d should disregard aromaticity at least, hoping that that fixes the fingerprint indexing problem... otherwise, we need to figure out why the fingerprints are so unstable; they should really just depend on the connectivity. > - structgen > > Original version needs to be tested (unit tests). Structgen atom > type list needs to be restored > to original version, so that unit test results can be compared to > that of the original version. Done. The original version was buggy too, and the deterministic structure generator code has been pulled from trunk and CDK 1.0.x too. > - forcefield > > No idea. May be nice to port the LGPL code of Bob for the UFF force > field, which also comes with geometry optimization code. The atom typing code merged with trunk yesterday makes it possible to perceive MM2 and MMFF94 atom types by perceiving CDK atom types and mapping these to the MM2 and MMFF94 schemes. This involves a lot of definition if finely granulated atom types, and postponed to CDK 1.3. SUMMARY So, the iterable patch is really the last major work on CDK 1.1. After that, I'll freeze trunk/ and will allow bug fixing only. If you like to develop new code this has to be done in a branch anyway. Any non-bug-fix-related commit to trunk *will be reverted without notice*, until the end of the freeze (I expect about 4 weeks later). That should get us to a couple of CDK 1.1 releases (sort of beta releases), and a CDK 1.2.0 somewhere in September. Egon -- ---- http://chem-bla-ics.blogspot.com/ |