-*- Mode:Text; Fonts:(MEDFNT) -*-

(hardcopy-file "it:keith;rowe-sw-versions.text"
	:page-headings nil
	:printer "cs-laser")

  
                                 MEMORANDUM
  
  TO:     Wendy Rowe
  
  FROM:   Keith Corbett
  
  DATE:   July 18, 1986

  SUBJ:   Proposed Software Version Numbering Scheme
  
  COPY:   John Salis, Ron Rando, Dan Thomas, John Conway

    
  My understanding is that LMI corporate management has agreed on
  the outlines of a formal bug fix/release methodology -- somewhat
  more of a philosophy than a procedure -- that is designed to
  address certain problems with software releases (such as waiting
  1.5 years between update releases). 
  
  One specific suggestion from Customer Service that has been
  endorsed is to revamp the software version numbering scheme.
  Currently, we have two parallel tracks, one used internally by
  Engineering, and one used by the rest of the company that is
  visible to customers.  For example, release 2.0: Engineering
  calls it "102.xxx"; as released it is "102.117", in another
  cut-off it is known as "102.187".  Similarly, 3.29 is "beta II",
  3.93 is "beta III", etc.
  
  This system is confusing and awkward.  Your software
  configuration system -- primarily the patches and DEFSYSTEMs --
  should be enhanced to work like most of the rest of the computer
  industry. Most companies use a version number scheme known to
  some as "R.V.U", where
  
     R = major release # (for major changes in functionality)
     V = point release (version) # (for bug fixes)
     U = individual update level (generally of internal concern only)
  
  For example, we could have a current version number (equivalent
  to our Beta III or system 3.93) of "3.0.93".  The last number
  (your patch level) would increment until a cut-off was
  established. The next patch would come at level "3.1.1", and
  would be the beginnings of a "version 3.1" or point release.
    
  One advantage of this is that any cut-off at "3.0.xxx" could be
  alternately referred to as "Release 3, version 0" or "Release
  3.0 at patch xxx".
    
  Another policy approved at the highest levels was that point
  releases would come every 3-4 months, miminum. 
  
  We need to decide whether to incorporate this scheme for the
  next point release (and just call it 4.0), or to do point
  releases through 1987 while aiming toward Release 4.

  Please add these issues to the agenda for the next Release 3.0
  project team meeting, and let me know when this meeting is
  scheduled and what else is on the agenda. 

  KMC