Mercury Coding Standard for the Mercury Project

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

Make sure configure.in is updated to check for new features.
Update the NEWS, RELEASE_NOTES, and HISTORY files. 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 `www' directory.
- 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://turiel.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.
Move the gzipped tar files from the /pub/mercury/beta-releases directory to the main /pub/mercury directory on the turiel ftp site ftp://turiel.cs.mu.oz.au/pub/mercury.
Email kostis@cs.sunysb.edu (Konstantinos Sagonas) to tell him to make copies of it on ftp://ftp.cs.sunysb.edu/pub/XSB/mercury respectively.
The mirror on ftp://ftp.csd.uu.se/pub/Mercury is supposedly automated.
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-core.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/www/mercury/mercury.html) by commiting the changes you made earlier.

Last update was $Date: 1997-11-17 07:37:59 $ by $Author: trd $@cs.mu.oz.au.