Release Checklist for the Mercury Project

This file contains a checklist of the steps that must be taken when releasing a new version of Mercury.

XXX Warning: this file looks to be very out of date.

  1. Items for the next version (1.0) only:
    1. Update w3/include/ as explained in the XXX comment there. Don't commit your changes to the main branch yet, because otherwise it would be installed on the WWW pages overnight.
    2. Make sure that the runtime headers contain no symbols (function names, variable names, type names, struct/enum tags or macros) that do not begin with MR_.
  2. Make sure is updated to check for new features.
  3. Update the RELEASE_NOTES, NEWS, WORK_IN_PROGRESS, HISTORY, LIMITATIONS and BUGS files, and the compiler/notes/todo.html file. Don't forget to update the version number in RELEASE_NOTES for major releases. The HISTORY file should include the NEWS files from previous releases (reordered if appropriate -- the HISTORY file is in cronological order whereas the NEWS file is in reverse cronological order).
  4. Update the WWW documentation in the `w3' directory. Note that the sources for these HTML documents are in the files named include/*.inc and *.php3.
  5. Use `cvs tag' or `cvs rtag' to tag all the files with a `version-x_y_z' tag. The cvs modules that need to be tagged are `mercury', `clpr', `tests', and `mercury-gcc'.
  6. Edit the tools/test_mercury script in /home/mercury/public/test_mercury/scripts/mercury: set the RELEASE_VERSION and CHECKOUT_OPTS variables as explained in the comments there.
  7. Run tools/run_all_tests_from_cron on earth. (Or just wait 24 hours or so.)

    This should have the effect of checking out a fresh copy, and doing

    	touch Mmake.params &&
    	autoconf &&
    	mercury_cv_low_tag_bits=2 \
    	mercury_cv_bits_per_word=32 \
    	mercury_cv_unboxed_floats=no \
    	sh configure --prefix=$INSTALL_DIR &&
    	mmake MMAKEFLAGS='EXTRA_MCFLAGS="-O5 --opt-space"' tar

    If it passes all the tests, it should put the resulting tar file in /home/mercury/public/test_mercury/test_dirs/earth/mercury-latest-stable and

  8. Test it on lots of architectures.

    Make sure you test all the programs in the `samples' and `extras' directories.

  9. Build binary distributions for those architectures. This step is now automated as part of tools/test_mercury, with the resulting binaries going in /home/mercury/public/test_mercury/test_dirs/$HOST/mercury-latest-{un,}stable.
  10. Make sure to test the binary distributions!
  11. Move the gzipped tar files from the /pub/mercury/beta-releases directory to the main /pub/mercury directory on the Mercury ftp site Copy the binary distributions to the same place.

    For the Stonybrook mirror, email Konstantinos Sagonas ( to tell him to copy them to

    Unfortunately this mirror is not automated, so don't worry about it except for major releases or important bug fixes.

    The mirror at is also automated. Sometimes the link to Sweden can cause delays. The person to contact regarding this one is Thomas Lindgren (

  12. Prepare a new "mercury-VERSION.lsm" file for this Mercury release (use the one already uploaded to as a template). The version number, date, file sizes, and file names need to be updated for a new release.
  13. Upload "mercury-VERSION-compiler.tar.gz" and "mercury-VERSION.lsm" to They will be moved to /pub/Linux/Incoming fairly quickly, and eventually should be moved to /pub/linux/devel/lang/mercury.
  14. Send "mercury-VERSION.lsm" to the lsm robot at with the subject "add".
  15. Append "mercury-VERSION.lsm" to a release notice and send it to This will post to comp.os.linux.announce.
  16. Email and cross-post announcement to comp.lang.misc, comp.lang.prolog, comp.lang.functional, comp.object.logic, and for major releases also to comp.compilers and gnu.announce.
  17. Update the Mercury WWW home page (/local/dept/w3/unsupported/docs/mercury/*) by commiting the changes you made earlier.
  18. For major releases, move the commitlog file from its current location (in $CVSROOT/CVSROOT/commitlog) into a file specific to that release, such as "commitlog-0.12". Create a new, empty commitlog file, making sure it is readable by everyone and writeable by group mercury (the commitlog file file is not managed by cvs itself, it is maintained by our own check-in scripts, so you don't need to do anything special to create this file). Email the local mailing list to say that you have done this.