-*- Mode:Text -*-

				Proposal

		      Generating Internal Releases

		  (Jim O'Dell / Last modified 11/08/88)



SUMMARY:



This document puts forth the philosophy, definitions, procedure,
and frequency for generating internal Falcon software releases over
the lifetime of Falcon software development.  The goals of
making internal releases are:
 
 o accommodation of individual and team project schedules;
 o provision of reliable snapshots of critical project components;
 o early detection of problems incurred by system file changes;
 o minimization of duration of required "code freezes";
 o minimization of disk space usage.



BACKGROUND:



The Falcon system software is currently found in the directory
"JB:K;", and may be referred to by a logical pathname,
"K:<subsystem>;".  

As always, logical pathnames may be redefined by a developer
wishing to use a different set of Falcon source and binary
files.

The files in the main line of Falcon system development (only)
reside in the directory "JB:K;". 



PROPOSAL:



The proposed release mechanism consists of six parts, each of
which will be discussed in the body of the proposal:

  1. Stating the Release Goals
  2. Beginning the Trial Run
  3. Making the New Falcon Release
  4. Compiling the New Falcon Release
  5. Publishing the New Falcon Release
  6. Archiving Old Falcon Releases

1. Stating the Release Goals

Before any Release of the Falcon System is undertaken, all K
developers must come to terms with exactly which state of the
world they wish to capture in making the release.  This is
accomplished by having each design group (individual or team)
make a formal (i.e., written or ZMailed) statement of the
particular design efforts they wish to complete before the new K
Release is begun.  In this manner, potential problems due to
module incompleteness at the time of the Release may be averted.
A critical example of this kind requires that the main line of K
development be able to support mega-booting before a new Release
is begun.

Conversely, a mechanism must exist for alerting the entire
development team of the completion (and need for Releasing) of
new major system components.  That is, a sufficiently radical
change to the main development line could warrant a release in
and of itself; in such a case, all other developers would work
to "the next convenient stopping point" and allow the Release
process to proceed.  In any event, no more than six months
should ever elapse between two Falcon Releases.


Before a Release is made, it is desirable to obtain some measure
of assurance regarding the system's current levels of
reliability.  To this end, a regression test should be run over
the


 Generating A Release Of The Falcon System Software

 
  Evaluate the form (make-k-system-release <host> <version>)

  where

  <host> is the name of the system host on which the release is
	 to be created (We are currently using "JB:")

  and
	
  <version> is the version number of the release. 

  Releases should be done when the relevant source files are relatively
quiescent; e.g., over the weekend.


 Finding The Current Version Number


  In the JB: root directory (obtainable by executing Dired on the
directory specification "JB:~;") will appear a series of directories
named "K-<version>" where <version> is a number.  The Release Version
Number is the number one greater than the <version> component of the
highest existing "K-" directory name.


 Compiling the Sources


  Requirements:  For now, it is necessary to recompile on a machine with
		 a Lambda installed.

  1.  Copy all source files into the trial directory "JB:TEST-K-SOURCES;".

  2.  Compile the copies, generating binary files into the
      "TEST-K-SOURCES" directory.

  3.  Repeat Step 2 until the system compiles correctly.

  4.  Run the regression test suite on the test system until minimal
      acceptability levels are recorded

  5.  Compile the original sources in the "JB:K-<version>"
      directory.

Steps 2, 3, and 5, involve the evaluation of the following forms, in
order:

	(load-k-system :recompile)

	(mega-boot :compile-type :recompile) 

If Steps 1-4 take more than a week to complete, the entire process shall
be repeated.


 System Maintenance Issues


Due to the limitations on disk space, only those
sources that are less than three months old will be kept online.
The only files that are exempt from quarterly deletion are those
without suffixes (such as .LISP, .QFASL, etc.)  These files
may be deleted only after discussion with the author.

COMMENTS:

STATUS: Open