draft announcement with some notes on future plans

• To: netcdf-hdf@xxxxxxxxxxxxxxxx
• Subject: draft announcement with some notes on future plans
• From: Russ Rew <russ@xxxxxxxxxxxxxxxx>
• Date: Mon, 09 Feb 2004 14:42:01 -0700

Hi,

Before I send this note out to the netcdfgroup mailing list, I'd like
to get any suggestions for changes from this smaller mailing list,
since it mentions netCDF-4 plans, HDF5 work, and Greg Sjaardema's
64-bit offset changes.  Please feel free to suggest changes.  Thanks!

 To: netcdfgroup
 Cc:
 Subject: Announcement: netCDF version 3.5.1 now available
 Reply-to: russ@xxxxxxxxxxxxxxxx
 Organization: UCAR Unidata Program
 Fcc: +outbox

 Hi,

 A new minor release of netCDF, version 3.5.1, is now available from

    ftp://ftp.unidata.ucar.edu/pub/netcdf/netcdf.tar.Z

 Version 3.5.1 is essentially the same as version 3.5.1-beta13.  It
 includes bug fixes, portability improvements, and performance
 enhancements.  The netCDF language interfaces and file format are
 unchanged, so files written with previous versions can be read or
 written with version 3.5.1.  For more information on the changes
 between 3.5.0 and 3.5.1, see the release notes:

   http://www.unidata.ucar.edu/packages/netcdf/release-notes-3.5.1.html

 Please report problems to support@xxxxxxxxxxxxxxxxx

 Soon we will be making available a beta-release of netCDF 3.6 that
 includes code contributed by Greg Sjaardema of Sandia Laboratories to
 supporting 64-bit file offsets for huge netCDF files in a way that is
 backward compatible with current programs and files.  If you aren't
 affected by any of the issues described in the release notes
 referenced above, you may want to wait for the 3.6 release.

 At the same time, we're working with NCSA developers on netCDF-4,
 which will provide a netCDF interface to HDF5 data and inherit some
 useful new features from the HDF5 underpinnings.

 We recently developed a prototype implementation of the netCDF-3 API
 using HDF5 as a storage layer. This implementation passed all netCDF-3
 tests and convinced us that 

  - using HDF5 as a storage layer for the netCDF data model is
    practical, and
  - backward compatibility with both netCDF-3 programs and data can be
    achieved by just recompiling and relinking.

 In addition, it helped to identify a few desired enhancements to HDF5
 to accommodate netCDF-4 more easily.  These new features have been
 specified in a requirements list, and the HDF5 team is working to
 implement them.  The prototype also demonstrates that read/write times
 and file sizes using the HDF5 format through a netCDF interface are
 reasonable.

 We can't support files written using this prototype, because it
 requires artifacts in the format that will no longer be needed when
 the necessary HDF5 enhancements are complete.  Nevertheless, the
 results are encouraging and we hope to release a supportable version
 by June 2005, barring unanticipated problems.

 -- Russ Rew
 -- Ed Hartnett