Version numbers

[Freddie Akeroyd]

> 
> You have presumably received the recent NeXus mailing list correspondance
> concerning NAPI version numbers.  I now realize that the CVS revision number
> is specific to each file and so has nothing to do with the overall version
> number.  We need to establish a version number policy fairly quickly
> answering the following questions:
> 
Yes, CVS puts a version number into each individual file. You can force a 
general update of all version numbers e.g. we can make all the 1.x numbers
into 2.0 for a release, then after more development with 2.x we can set it
at 3.0 etc. However, the way CVS usually does project versioning is by use of a
symbolic tag - you would associate a name such a VERSION_1_0 with
a set of 1.x version files, and then could access that set of files at any
later time using the name symbolic name VERSION_1_0
>
> 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 
>
> Who documents what changes have been made since the previous version?
> 
Whenever you put back a file with CVS, you have to include a LOG comment.
If people are sensible with these comment, they could be collected together 
to form "release notes"
>
> Who tests a version before it's released to make sure that no egregious bugs
> have been introduced?
> 
Probably best if testing is done by somebody not involved in doing the coding -
nobody likes breaking their own programs :-) We will need a set of test 
programs developing though

Freddie

-- 
Freddie Akeroyd                        Email:  Freddie.Akeroyd at rl.ac.uk
ISIS Facility                          Tel:    +44 1235 445457
Rutherford Appleton Laboratory         Fax:    +44 1235 445720
Chilton, DIDCOT, OX11 OQX, GB          WWW:    http://www.isis.rl.ac.uk/