Release and Testing Process

As part of delivering a high quality product (and another way the Repertoire Project sets itself apart from other C++ libraries), a formal release process is followed. This is designed to ensure that all the i's are dotted etc. when preparing a new public release. You can be sure that all the little details were taken care of, all the code compiles, and all the code has been regression-tested against previous versions.

Besides saving you, the library user, from certain kinds of upgrade headaches, simply having a documented process is an important step. Because of this, the Repertoire Project libraries are more conducive to industries that follow quality standards in manufacturing. In fact, as far as I know, this is the first general purpose publicly available software library to document the release process for its customers.

So, you can judge for yourself whether it meets with your own standards, rather than hoping what you buy has some measure of quality. You can also offer feedback and suggestions concerning the release process, so that it may continue better to serve the needs of the library user.

Below is what was followed for release "public build 5".

  1. First, recompile everything to make reasonably sure the rest of this is not premature.

  2. Check out all files from source control. Use a newly created working directory, not the directory that had been used during development. So, the only files present are those that are properly under revision control.

  3. Update all files to indicate the current build information. This process is completely automated with the use of the version_stamp.perl file. The steps to perform are:

    1. Update the comment block at the top of each source file.

    2. Create the new version check include files. (not yet available)

    3. Update the version ID include files. (not yet available)

    4. Update the revision info resource blocks. (not yet available)

    5. Update the project .dsp files to reflect the libraries' version number in their names. (process each set of supported project files, currently VC5 and VC6)

  4. Check the modified files back in.

  5. Create a new Source Safe project that's a copy of the current work, "pinning" all the files. This new project is named after the release, and is Source Safe's way of "labeling" a build with all the specific file version and directory content information.

  6. Compile all the libraries and test code, for each configuration. (VC5 and VC6). Document any warnings or special issues in the release_xxx_log.txt file. Any minor problems fixed at this point can be checked in and the "pin" promoted. Any temporary fixes that are just to get this version working can "branch" the shared file along this project. Any major changes require starting over. After any such spot change, always use a global "get latest" to make sure that the build directory stays in sync with the official labeled point in the source control.

  7. Run all the automated unit tests in the "release" builds of each configuration. Document any warnings or failures in the release_xxx_log.txt file.

  8. Delete the intermediate files

  9. Zip up the source code, readme files, DLLs, and unit tests. Source, debug info, and binaries for both vc5 and vc6 are in one zipfile, for simplicity.

  10. Place the ZIP files in the local Web Mirror area, in preparation for updating the server. Also update the Downloads page and the Footer to indicate these new files.

  11. Update the Web Server with the new and changed files. Interested users will be using existing web-change monitors to inform them that the new version is available.

  12. After a yet-to-be-determined period of time, assuming no problems have been found, rename the "release candidate" files to the "release" files, and update the links and Footer notes. If problems are found, re-prepare the "candidate" after fixing the problem.

Documentation Release Process

In general, the documentation process is not as formal as the code release process. There is no requirement to keep archives of "official" labeled versions, and minor updates and corrections can be made much more casually.

This "release" process describes the creation of the downloadable complete documentation packet. The main concern is making sure all the embedded dates and version numbers are changed.

  1. Put the correct date in the footer.html and static.html files.

  2. Zip up the downloadable copy by creating "refman\Repertoire Documentation.zip" file from the contents of "refman\". Don't include the old copy of the zip when creating a zip from all files! Delete the old zip file first, if it exists in the local mirror.

    When creating the zip, make sure that path information is included and that paths are relative to "refman\".

  3. Inspect the ZIP file

  4. Update the Web Server, copying all files including updated documentation and the new ZIP file.

  5. Inspect the new on-line reference manual by browsing it.

  6. Navigate to the Download site and download the ZIP just created.