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.

Items for the next version (1.0) only:
1. Update w3/include/globals.inc 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_.
Make sure configure.in is updated to check for new features.
Update the RELEASE_NOTES, NEWS, WORK_IN_PROGRESS, HISTORY, LIMITATIONS.md 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).
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.
- Update the RELEASE_INFO file with the name and CVS tag of the new release.
- 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. This should be the same as the BUGS file.
  release-VERSION-contents.html
  The contents of this distribution. This should be the same as in the RELEASE_NOTES file.
  You will need to add these new files to the list in the Makefile. You will also need to update release.html and current-release-bugs.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.
- Update the CURRENT_RELEASE and BETA_RELEASE variables in tools/generate_index_html so that the new release is listed first on the download page.
- Don't commit your changes to the main branch yet, because otherwise it would be installed on the WWW pages overnight.
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'.
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 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 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.
Make sure to test the binary distributions!
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.
For the Stonybrook mirror, email Konstantinos Sagonas (Kostis.Sagonas@cs.kuleuven.ac.be) to tell him to copy them to ftp://ftp.cs.sunysb.edu/pub/XSB/mercury.
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 automated. Sometimes the link to Sweden can cause delays. The person to contact regarding this one is Thomas Lindgren (thomasl@csd.uu.se).
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.
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 with the subject "add".
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.
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.