_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
