How to prepare a VAOS release

The notes here take the form of a checklist for producing a full VAOS release as an installer package and uploading it to SourceForge. Remember that the uploaded package is going to be accessible to persons interested in using VAOS all over the world – don't skimp on checks or tests!

I'm going to assume that all new development that is to be part of the new release is in the CVS trunk (it has either been done in the trunk or has been merged in) and has been tested, and that the user has a working space that contains the code from the trunk. I'm also going to assume that the Boost libraries are present on the build PC and are installed in the "Tools" "Options" "Projects and Solutions" "VC++ Directories" settings in Visual Studio so that they will be picked up automatically. Use the latest stable version of Boost that is known to work with VAOS.

Note: No other developer should commit anything to the CVS branch from which the release is being made. If the release is being made from the trunk it may be necessary to ensure that other developers refrain from making commits while the initial update, commit, and tag actions are made. After that the release will have its own branch and others can carry on working on the trunk.

Note: You may not have the necessary tools to compile the VAOS components that are in Pascal/Delphi. If that is the case – and there have been no changes to those components – then just copy the executables from the previous version of VAOS.

Update VAOS version numbers and copyright dates

Make sure that the version and string resources that hold versions and dates are current and correct. Don't forget that different components may have their own resource files that may need to be updated separately.

Remember that the installer package also has a version number (in the VA_install.nsh file) and that some of the various text files that are copied by the installer (in the installer/texts directory) will also need to be updated.

Ensure that the version(s) of the build tools and Boost libraries that will be used to build the release code are noted in the readme.txt file.

Make sure that all the .history files are up to date, and insert a line in each file noting the date and release version number in the form:

[---- ----] 2011-06-06

Merge any updates on CVS into your working copy.

CVS won't let you commit changes to the repository if your workspace is based on old versions of the files, so you must first do a CVS "update" to merge the other developers' work into your workspace.

Rebuild your project and retest

If the update process has merged new code into your workspace you must now rebuild your code and retest your changes and the changes that you have merged in. It's difficult to say exactly what tests should be carried out – especially on the other developers' code – but do try to ensure that the merge hasn't broken any behaviour, new or old.

Commit all your changes to CVS

This brings the repository up to date.

Tag the the repository

Create a revision tag for the whole of the current branch (which will probably be the HEAD) of the repository. For consistency with earlier releases the tag name should have the form BUILD_1_2_0_3 for VAOS 1.2 Build 3.

Create a CVS Branch for the release

Create a CVS branch using the revisions tagged in the previous step. For consistency this branch should have a name of the form BRANCH_1_2_0_3.

The reason for having a branch and a tag is that the changes made to any file on that branch can be found by doing a CVS diff between the tag name and the branch name.

Checkout the branch into a new workspace

In order to verify that the branch has been created correctly and that it contains a complete and consistent set of VAOS sources you should now check out the whole project into a new working directory.

Don't forget that aspell.h is part of the GNU Aspell project and not of VAOS, so you'll need to fetch that separately to build the vasp_asp.dll spellchecker wrapper.

Rebuild and retest

Build the whole VAOS suite in the new working directory and retest.

We don't have a format test suite for VAOS (nor is it easy to construct a reproducible set of tests for an application like VAOS) so exactly what tests need to be performed is a matter of discretion. At the very least the tests should ensure that VAOS runs, can display messages, can fetch messages from a mail server, from a newsgroup, and from CIX.

Take care to note that all the new copyright dates and version numbers displayed.

Build the installer package

Run the NSIS installer compiler to build the installer package.

Test the installer package

The installer should be tested by running it to install VAOS – checking throughout that the correct version numbers and copyright dates are shown – and then by running the installed copy of VAOS to ensure that a working installation results. If any changes have been made to the installer script then the installer should be tested in a variety of common installation scenarios:

  • Different versions of Windows (currently XP, Win7, and Win7 x64) and if possible Wine on Linux
  • Installation as user and as administraor.
  • Fresh install (on a PC that has never had VAOS installed) and upgrade install.

In each case the resulting VAOS installation should be tested to ensure that the installation has been successful. Again, it's not possible to give a complete list of the tests performed but you should test that messages can be displayed correctly and that internet mail and news as well as CIX messages can be sent and received.

Fix It!

If, at any stage, you encounter a build error, a VAOS bug, or simply a date or version that hasn't been updated, correct the code in the branch and repeat the building and testing from that point.

Remember to merge the changes back into the trunk afterwards!

Tag Again

When you are satisfied that the code is all correct and that the release package has been correctly built it is a good idea to tag the release branch again with a tag whose name has the form RELEASE_1_2_0_3. This ensures that there can be no uncertaintly as to which version of any file was used for that build, even if someone later edits one of the files in the release branch and commits it (perhaps for a bugfix on that branch).

Build a sourcecode snapshot archive

Perform a another complete checkout of the final sourcecode set into a new working directory, and add the aspell.h file; then create a zip archive of that directory tree as a development snapshot. Give the snapshot file a name of the form

This step is optional, but it's a good idea as it enables users who'd like to play with the sourcecode themselves to get a working copy without having to deal with SourceForge's anonymous CVS access (which is sometimes very slow).

Upload the release to SourceForge

This step is much easier than it used to be – no mucking about with FTP to upload the files to a temporary staging area on the server before adding them to the VAOS file area – it's all done through the browser (Hurray!)

Log into SourceForge and go to the VAOS project page.

  • Click "Files" and select the "VA - v6 - Binaries" folder.
  • Click "Add folder" and create a new folder with a name of the form
  • Click "Add File" and add (upload)
    • the source snapshot
    • the readme.txt file
    • the changes.txt file
    • the installer package
  • Set the default download package to the new installer package (for all OSes)

You can also add a "News" item on the SourceForge project page to announce the new version.

devinfo/howtorelease.txt · Last modified: 01.09.2011 19:21 by daniel
Recent changes RSS feed Driven by DokuWiki