Last updated: April 28, 2006

Making a Product Release

Several times during the semester you will be required to deliver a version of your product to the customer.  Each of these deliveries is called a “release.”  A typical project will provide three partial capability releases, a beta release, and a final release.  Your customer may request additional releases or you may decide that it is more convenient to deliver in finer granularity. 

You and your customer work together to determine and prioritize the product feature, but the customer has the final say regarding the relative priority of features.  On the other hand, you must figure out which features you can complete and how best to deliver those features over the course of the semester through the series of product releases.

Partial capability releases are produce at predetermined points during the semester.  Each one provides your customer with the product capabilities (features) that you have developed up to that time.  This gives you the opportunity to get early feedback from your customer about the direction you’re taking.  This will help minimize the likelihood of a major surprise when you make your final product delivery.  In addition to delivery of new features, releases also deliver defect fixes, and documentation.  The first release you make may be intended to prove out a basic product concept or to help the customer flush out requirements details.  All releases, even ones delivering partial capabilities, must be thoroughly tested and evaluated before delivery.  Although you test extensively, you probably won’t be able to find all the defects in your code.  So a release has the unfortunate side effect of delivering some defects as well.  What you want to make sure is that you don’t waste your customer’s time dealing with defects that you should have found with your systematic testing.

The beta release contains all agreed to functionality.  It is provided to the customer so that he/she can do additional testing in the final environment.  Normally, the beta testing activity will identify a few more defects many of which are the results of unanticipated usage and differences between the development environment and the customer’s environment.

The final release contains the functionality provided at beta release plus defect fixes for all defects that the team and the customer have agreed require fixing.  Some defects may be considered to be of low value or too high a risk to be fixed and are therefore present in the final product..

The important points to remember about a release are:

• The primary objective of a release is to deliver meaningful functionality (features) to the customer that the customer can evaluate and on which he / she can provide feedback.

• A release delivers the functionality upon which you and your customer have agreed

• The release is more than a delivery of functionality.  It includes the executable code, source code, help files, scripts, data, tests, documentation, and release notes as appropriate and as agreed to with the customer.

• The exact content of the release is known by the team.  This means that you are careful to incorporate the correct version of all code in your build and the documentation supplied with the release matches what you are delivering.  All of the version information is documented in the release notes.

• You institute a feature freeze prior to the time when you start running your release qualification tests.  No last minute changes to functionality are introduced after the feature freeze.  The only thing permitted is to fix serious defects.  Once a fix is in, you freeze the code again and retest.  On this front, the last thing you do is achieve a successful execution of your test suite and obtain the expected results.  At this point you freeze the code and label it in CVS.  No more code modification is permitted in this release.

• A release is fully tested and of production quality.  This means you have run all applicable parts of your test suite and you know the quality of your release.  If there are minor defects found during formal testing that are not fixed prior to delivery, they are documented in the defect log and in the release notes.

• Qualification (testing) of the current release has higher priority than development of features for a future release.

• Development of your product and preparation of the release are to be performed in a configuration controlled environment using a revision control system.  If there's work being done on the next release you have to ensure that it doesn't "contaminate" the current release.

• Each release is to be labeled (identified) with a release version that increases for each subsequent release.  The release is built from known and documented versions of its components.

• When executed, the release provides easy access to information that identifies the version being executed. For Windows-based programs this can appear on an initial splash screen or in an about box.  For Unix-based programs this can be provided via a console message or a help command.  The version displayed is to change with each release.

• If the program contains a help file or man page, the help file or man page will identify the version of the program it supports.

• It is highly desirable to deliver a regression test suite along with your product delivery.  The intent here is for your customer to be able to run the regression suite in his / her environment to determine that the program functions in that environment.

• A set of release notes will be prepared and included in the release.  The release notes are to identify the content of the release, what pieces (components) should be in the release and their version being delivered, and describe installation procedures.  The release notes will identify the new features or functionality provided in the release and will identify any functionality present in the prior release that has been removed.  The release notes will also identify any limitations or know defects in the program.  Limitations may address features that are not yet implemented, or provide guidance on how to work around known defects.  When identifying the known defects, describe them in terms that the customer will understand with a focus on the operational impact of each defect.

• The release is packaged into a single transportable entity such as a tar or zip file.

• Just to make sure that your packaged release works as intended, you will take the package and install it just as your customer is going to do (possible exceptions might be made if the customer’s environment is different from your own).  You then verify that the installation contains the correct versions and that it works as intended.

• The release is posted to the team web site.

• A member of the team verifies that the posted release is accessible and that it is complete and contains the correct version of all released items.

• An agenda is prepared and distributed announcing the release presentation meeting.

• The team prepares and presents their release at a formal meeting with the customer.  The release presentation uses PowerPoint slides to address the feature content, known limitations, known defects, and testing status.  In most cases the presentation will also address what the team plans to be doing on the next phase of the project.  The team knows and communicates to the customer what they want the customer to do with the release and reaches an agreement with the customer when results will be reported.  The presentation is made available on the team web site prior to the meeting.

• Minutes of the release presentation are written, distributed, and posted to the team web site.

• Following posting of the release to the team web site, the team needs to be prepared to respond to any blocking defects that prevent the customer from performing the desired release evaluation in his / her environment.  A blocking defect is one that severely limits what the customer is able to do with the product.  Should the customer report a suspected defect, the team must quickly acknowledge (within a few hours) the receipt of the report and begin an investigation.  The team should report back to the customer on what they find and discuss possible corrective action and its impact with the customer.  If the problem is confirmed to be a product defect an entry for it must be created in the defect log.