Current Release: 4.72.

It is a patch release of 4.71. Main feature: Cartridge on SGI and Linux. Also, support for 8i Standard Edition. Includes bug fixes to clogp, libdt_smiles.so, thorserver, merlinserver, dayutilserver.

The next several releases will be transitional for Daylight. Over the last five+ years we've added support for new technologies (Java, Oracle, CGI, Perl), new systems (Linux, 64-bit IRIX), and literally thousands of new source files.

To a certain extent our internal development and testing tools haven't kept up with the growth in complexity of our code base. The result is that building, testing, and delivering a release requires more and more manual effort.

Our release cycle has stretched out. We aren't getting features and fixes into the customers hands as quickly as we'd like. Pressure to get features/fixes into each release has increased, as the delay to wait for the next release gets longer.

This leads us to the conclusion that we need to spend some effort on our internal Development tools / procedures. This includes better code management, automated testing, and delivery.

I'm proposing that we change our development/release cycle as follows:

• One "feature release" per year.
  • New features/capabilities,
  • Incompatible changes to current capabilities (languages, toolkits, api's, servers),
  • Removal of deprecated/discontinued products,
  • Full documentation update.

• Frequent maintainence/patch releases.
  • Bug fixes,
  • Fully-compatible changes to capabilities,
  • New, compatible features,
  • Documentation of changes.

An additional step, which will be somewhat longer term, and I'm less comfortable advocating, is the idea of decoupling our various products and having them be released on their own schedules. For example, the Oracle Cartridge could be released on a schedule which matches Oracle's release schedule, rather than one which we set. The reason I'm not sure that this is a good idea is that fact that everything we support depends at least on the smiles toolkit. It isn't completely obvious how we'd manage the dependancies. In any case, this will be a longer-term change.

I'd appreciate hearing feedback from users/administrators about this proposal.

4.8 Platforms:

• Solaris (Versions 7, 8)
  • Toolkits, applications, servers, cartridge as 32-bit objects,
  • Toolkits, merlinserver only as 64-bit objects (like current IRIX).
  • No support for Solaris 2.5, 2.6.

• IRIX (Version 6.4+)
  • Toolkits, applications, servers as 32-bit objects (-N32 only),
  • Toolkits, merlinserver, cartridge as 64-bit objects.
  • No support for -O32 libraries (xview ported to -N32!!!).

• LINUX (Red Hat 6.2)
  • Toolkits, applications, servers, cartridge as 32-bit objects.

• Windows 2000 Professional
  • Cartridge initially.

4.8 Features:

• Platform items:
  • 64-bit Toolkits/merlinserver on Solaris,
  • Testing and support for Solaris 8,
  • XVIEW libraries ported to -N32 on SGI.

• Licensing:
  • Been an issue for several years.
  • Added pressure now with network licenses, Linux clusters.

• Oracle:
  • Commercial database distributions,
  • Lots of new (smallish) features,
  • CLOB support,
  • Cartridge on NT.

• Virtual Chemical Stores (VCS):
  • Tools, interfaces, databases.

• JavaGrins:
  • Run under IE with Java plugin,
  • Run as a native Windows application, and ActiveX control,
  • Reaction SMIRKS interface.

• Multithreaded Toolkit:
  • Some work still to do,
  • Will require significant changes to the low-level toolkits.

• Linux Clusters:
  • Not sure what to do here, but gaining some experience will be valuable.

• Interface Delivery Tools:
  • Java, JSP, XML, VML,
  • HTTP Servers,
  • Oracle.

Summary of Major Directions:

Cartridge continues to be the main thrust for database development work,

Windows will be taken seriously as a platform,

New or replacement Interfaces for Oracle, Daycgi, Thor, Merlin.