version numbers

[Ray Plante]

Hi VOers,

Now and again I see someone asking about the logic behind a version
number, wondering how vZ.Z.ZZ came after vX.X.  I'm sure I've confused my
fair share of people with my own choices.  I would like to recommend that
we practice the pattern typical of most revision control systems (that I
am aware of), as in the following example of a sequence of version
numbers:

     0.1         // an initial pre-production draft version
     0.2
     0.2.1       // a minor revision on 0.2
     0.2.2
     0.4         // perhaps 0.3 never saw the light of day
     0.8
     0.9
     0.10        // we're not ready for 1.0 yet
     0.11
     0.11.1      // further refinement
     0.11.2   
     1.0         // yeah!  ready for prime-time!
     1.1         // revision on 1.0
     2.0         // major revision over 1.x; applications may break.

This is based on the following principles:

  o  Each field between a period (.) is an integer.  The version is not 
     to be interpreted as a floating point number.  That is 0.91 is 82
     revisions after 0.9.

  o  When the first field is 0, the standard/app is a draft release 
     with significant development or review still expected.  

  o  The third field is a branch in development.  In our case, we should 
     use this to mark minor changes (perhaps backward compatible) beyond 
     the last two-field version. 

  o  An increment in the first field represents a major change; users will 
     likely have to change their applications to be compliant with the new 
     version.  
  
  o  Which field is incremented--that is, whether this is a minor or major 
     change--is up to the authors.  

cheers,
Ray