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.

Items for the next version (0.9) only:
1. Remove the bootstrap-only code from runtime/mercury_ho_call.c, which are (a) three closure call routines, (b) three method call routines, and (c) a backward compatibility check in the new closure call routine.
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_.
3. Ask Philip to check in muz, preferably with documentation.
Make sure configure.in is updated to check for new features.
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.
Update the WWW documentation in the `w3' directory. Note that the sources for these HTML documents are in the files named include/*.inc files.
- For minor releases, update release.html with a new entry about this release (put it at the top of the page), and provide a new link to download the release. See old-release.html for examples.
- For major releases, you will need to create some new web pages:
  
  release-VERSION.html
  The release notes for this version.
  release-VERSION-bugs.html
  Any outstanding bugs for this release.
  release-VERSION-contents.html
  The contents of this distribution.
  You will also need to update release.html. Move the old information in release.html to old-release.html. Modify release.html to refer to the new html files you have created, and change the links to download the release.
- Don't commit your changes to the main branch yet, because otherwise it would be installed on the WWW pages overnight.
Use `cvs tag' to tag all the files with a `version-x_y_z' tag.
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.
Run tools/run_all_tests_from_cron on murlibobo. (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" -j6' tar
	
```
If it passes all the tests, it should put the resulting tar file in /home/mercury/public/test_mercury/test_dirs/mercury-latest-stable and ftp://ftp.mercury.cs.mu.oz.au/pub/mercury/beta-releases.
Test it on lots of architectures.

Make sure you test all the programs in the `samples' and `extras' directories.
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.
Move the gzipped tar files from the /pub/mercury/beta-releases directory to the main /pub/mercury directory on the Mercury ftp site ftp://ftp.mercury.cs.mu.oz.au/pub/mercury. Copy the binary distributions to the same place.
The mirror at ftp://ftp.ntua.gr/pub/lang/mercury is automated; it should automatically mirror the Mercury ftp site at ftp.mercury.cs.mu.oz.au on a nightly basis (or thereabouts). But in case anything should need changing, the person to contact there is Yiorgos Adamopoulos and/or ).
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 ftp://ftp.csd.uu.se/pub/Mercury is also supposedly automated; however, it seems to be often quite out-of-date (due to the connection dropping and/or timing out over the rather slow link to Sweden?). The person to contact regarding this one is Thomas Lindgren . XXX Currently it is mirroring turiel, not ftp.mercury.
Prepare a new "mercury-VERSION.lsm" file for this Mercury release (use the one already uploaded to ftp://sunsite.unc/edu/pub/Linux/Incoming as a template). The version number, date, file sizes, and file names need to be updated for a new release.
Create new binary packages for Linux packaging systems. The .spec file can be used to create .rpm packages. The command dpkg-buildpackage -rfakeroot on hydra can be used to create .deb packages, although you should probably let (or make) the official maintainer do this so it can be PGP signed and uploaded.
Upload "mercury-VERSION-compiler.tar.gz" and "mercury-VERSION.lsm" to ftp://sunsite.unc.edu/incoming/Linux. They will be moved to /pub/Linux/Incoming fairly quickly, and eventually should be moved to /pub/linux/devel/lang/mercury.
Send "mercury-VERSION.lsm" to the lsm robot at lsm@execpc.com.
Append "mercury-VERSION.lsm" to a release notice and send it to linux-announce@news.ornl.gov. This will post to comp.os.linux.announce.
Email mercury-announce@cs.mu.oz.au 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.
Update the Mercury WWW home page (/local/dept/w3/unsupported/docs/mercury/*) by commiting the changes you made earlier.

Last update was $Date: 1999-04-16 06:20:47 $ by $Author: trd $@cs.mu.oz.au.