Version numbers

[Ray Osborn]

>>
>> When do we increment the version number and at which level? (which new
>> features have been added? bugs fixed?) 
>> 
>We have to increment the version number whenever a new version is made
public.
>My WWW page was for people to try out the kit "in beta" before it was
>placed on general distribution - if we agree with using a "tag" process, i
can
>put a list of these onto the WWW pages so that people can check out 
>"the latest" or "any previous public version"
>We may want to use a three figure version number e.g.
<major>_<minor>_<patch>
>so that 1.0.0 to 1.0.1 is a bug-fix, whereas 1.0.1 to 1.1.0 is a 
>functionality increase. Changes in the major version number e.g. to 2.0.0
would
>be used for BIG changes e.g. file format changes or moving to HDF5 

OK, I agree with all Freddie's suggestions.  I suggest that we take a vote
then about whether we can release the current version of NAPI as v1.0.0 just
to establish a baseline.  Mark has probably the most operational experience
of the current code, so he could probably veto this if he knows of any
serious problems.  Otherwise, we are in danger of being in perpetual
beta-mode.  If someone wants to propose some test programs for us to run
first, please do.

Before finalizing on version 1.0, I would like to raise one issue again. 
When I was at NIST recently, Przemek showed me some of his NeXus code, which
contained a subroutine to automatically perform the NXmakedata, NXopendata
and NXputdata trilogy.  Jon Tischler's example had a similar subroutine.  I
really think that we should provide a standard one as part of NAPI to save
this endless typing.  To hurry this process along, I wrote one possible
version of this, with the hope that the C code is so bad that someone
quickly corrects it (installing the correction in NAPI.C using CVS).  

Here is my code which creates two new routines, NXwritedata and NXreaddata,
to perform the multiple functions:

  NXstatus NXwritedata (NXhandle fid, char *name, int datatype, int rank,
              int dimensions[], void *data, char *units)
  {
  
    if (NXmakedata(fid, name, datatype, rank, dimensions) != NX_OK) return
NX_ERROR;
    if (NXopendata(fid, name) != NX_OK) return NX_ERROR;
    if (NXputdata(fid, data) != NX_OK) return NX_ERROR;
    if (NXputattr(fid, "units", units, strlen(units), NX_CHAR) != NX_OK)
return NX_ERROR;

    return NX_OK;
  }
  
  NXstatus NXreaddata (NXhandle fid, char *name, int *datatype, int *rank,
              int dimensions[], void *data, char *units)
  {
    int32 attr_len;
    int32 attr_type;

    if (NXopendata(fid, name) != NX_OK) return NX_ERROR;
    if (NXgetinfo(fid, rank, dimension, datatype) != NX_OK) return NX_ERROR;
    if (NXgetdata(fid, data) != NX_OK) return NX_ERROR;
    if (NXgetattr(fid, "units", units, attr_len, attr_type) != NX_OK) return
NX_ERROR;
    
    return NX_OK;
  }

Please find the deliberate mistakes and correct them.  Of course, if Mark
wants to rewrite them using the underlying HDF routines, that's fine by me. 


Regards,
Ray
-- 
Dr Ray Osborn                Tel: +1 (630) 252-9011
Materials Science Division   Fax: +1 (630) 252-7777
Argonne National Laboratory  E-mail: ROsborn at anl.gov
Argonne, IL 60439-4845