Memory Pool System Experimental-Release Procedure

1. Introduction

This is the procedure for making an experimental release of the Memory Pool System.

An experimental release is a cheap and quick way to make under-development MPS code available to external parties (eg. customers), typically to let them evaluate new functionality. See Justification, below.

The intended readership of this document is Ravenbrook development staff. (If you are a user of the MPS, and want to build object code from an mps-kit, please see the readme.txt file in the kit).

This document is not confidential.

2. Procedure

2.1. Prepare your modified MPS source

Make your changes in a development branch: branch/YYYY-MM-DD/NAME/. (In the rest of this procedure, relative paths assume you have cd'd to this directory).

2.2. Determine release name and origin

An experimental release's name is simply the Perforce changelevel of its origin, prefixed with "exp-".

The following procedure is cheap and usually works, despite the race condition.

1. p4 changes -m 1, add 1: this is the expected changelevel NNNNNN for your experimental release.

2. Edit code/version.c: set MPS_RELEASE to "exp-NNNNNN".

3. Edit code/w3build.bat: @set mpsreleasename to "exp-NNNNNN".

4. Submit code/version.c and code/w3build.bat.

5. p4 changes -m 1 to check that you did indeed get changelevel NNNNNN.

If someone else grabbed your intended changelevel, repeat until you win.

2.3. Make the release package

This example is for an experimental release to Configura.

1. Clean directory, Sync to origin, Build:

     p4 sync code/...#0
     rm -rf code
     p4 sync code/...@NNNNNN
     code/w3build.bat

2. Make Zip Archive, in development branch's release directory, using Windows GUI:

   • browse to code/exp-NNNNNN
   • right-click > Send To > Compressed (zipped) folder
   • prefix archive name with "MMconfigura-"
   • place in release/

   release/ is a new "branch release directory", a peer of the /code directory. It is only present in branches from which we make experimental releases. Experimentally released files go here, for example: //info.ravenbrook.com/project/mps/branch/2007-04-18/diag/release/MMconfigura-exp-162399.zip.

3. Add to perforce:

     p4 add -t binary release/MMconfigura-exp-162399.zip
     p4 submit ...

   or equivalent.

2.4. Test and Publish

1. Test as appropriate.

2. Make webserver allow access to the release: see http://info.ravenbrook.com/procedure/webserver/.

3. Send email, including your (informal) release notes, and a link to the release on www.ravenbrook.com...zip (not info.ravenbrook.com!).

3. Justification and Design

An experimental release is a cheap and quick way to make under-development MPS code available to external parties (eg. customers), typically to let them evaluate new functionality.

This procedure was designed by simplifying and removing steps from the formal release-build procedure. For design justification, see http://info.ravenbrook.com/mail/2007/05/23/17-34-46/0.txt and http://info.ravenbrook.com/mail/2007/05/24/12-40-54/0.txt.

A. References

B. Document History

C. Copyright and License

This document is copyright © 2007-2008 Ravenbrook Limited. All rights reserved. This is an open source license. Contact Ravenbrook for commercial licensing options.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
3. Redistributions in any form must be accompanied by information on how to obtain complete source code for the this software and any accompanying software that uses this software. The source code must either be included in the distribution or be available for no more than the cost of distribution plus a nominal fee, and must be freely redistributable under reasonable conditions. For an executable file, complete source code means the source code for all modules it contains. It does not include source code for modules or files that typically accompany the major components of the operating system on which the executable file runs.

This software is provided by the copyright holders and contributors "as is" and any express or implied warranties, including, but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement, are disclaimed. In no event shall the copyright holders and contributors be liable for any direct, indirect, incidental, special, exemplary, or consequential damages (including, but not limited to, procurement of substitute goods or services; loss of use, data, or profits; or business interruption) however caused and on any theory of liability, whether in contract, strict liability, or tort (including negligence or otherwise) arising in any way out of the use of this software, even if advised of the possibility of such damage.