Re: Java netcdf 2.2

• To: Donald Denbo <Donald.W.Denbo@xxxxxxxx>,
• Subject: Re: Java netcdf 2.2
• From: John Caron <caron@xxxxxxxxxxxxxxxx>
• Date: Mon, 17 Oct 2005 17:56:47 -0600

_From caron@xxxxxxxxxxxxxxxx  Mon Oct 17 17:56:53 2005
Received: from [128.117.140.172] (dhcp12.unidata.ucar.edu [128.117.140.172])
        by unidata.ucar.edu (UCAR/Unidata) with ESMTP id j9HNuq7s011304;
        Mon, 17 Oct 2005 17:56:52 -0600 (MDT)
Organization: UCAR/Unidata
Keywords: 200510172356.j9HNuq7s011304
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
        support-netcdf-java@xxxxxxxxxxxxxxxx
References: <4C6866BE-A80F-405F-BA2B-C1D32EEBABD1@xxxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on 
        laraine.unidata.ucar.edu
X-Spam-Level: 
X-Spam-Status: No, score=-5.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 
        autolearn=ham version=3.0.1

Hi Don:

Donald Denbo wrote:
> John,
>     I have just recently looked, for the first time, at the netcdf  2.2 
> libraries.  I immediately noticed that this version is not upward  
> compatible from the previous version (2.1).  Given the amount of time  
> that will be required to port ncBrowse from netcdf 2.1 to netcdf 2.2  
> I'm curious how stable is the version 2.2 API?  I note that it does  say 
> (alpha) so I'm a little reluctant to put the effort until the API  has 
> settled down.

The lower level, particularly ucar.nc2.NetcdfFile are related is pretty stable, 
though things are still moving around a _little_ bit. The upper levels ( like 
ucar.nc2.dt) are still going to change a lot. 

Id say if you are just going to replace 2.1 functionality, it should be a 
reletively easy port.

> 
>     Given that the conversion from 2.1 to 2.2 does require a re- coding 
> of much of ncBrowse, I'm curious why you make only a minor  version 
> change when the API is quite different?  The change from 2.1  to 2.2 
> seems greater to me that from version 1 to version 2 (at least  there 
> was an  upgrade path there).  I think calling it version 3.0  and 
> creating nc3, etc, would allow a developers to keep a single  netcdf 
> library for development rather that keeping track of two  incompatible 
> libraries.

No good reason for where the version number is incrementing, just the usual 
history etc. Sort of like JDK 1.5 becomes 5.0 I guess. Anyway were kind of 
stuck with it for now.

John