This file describes the testing procedures for Fossil prior to an official release.
- From a private directory (not the source tree) run "tclsh $SRC/test/tester.tcl $FOSSIL" where $FOSSIL is the name of the executable under test and $SRC is the source tree. Verify that there are no errors. 
- Click on each of the links in in the ./graph-test-1.wiki document and verify that all graphs are rendered correctly. 
- Click on each of the links in in the ./diff-test-1.wiki document and verify that all diffs are rendered correctly. 
- Click on the following link to verify that it works: ./test-page++.wiki (NB: Many web servers automatically block or rewrite URLs that contain "+" characters, even when those "+" characters are encoded as "%2B". On such web servers, the URL above will not work. This test is only guaranteed to work when running "fossil ui".) 
- Shift-click on each of the links in ./fileage-test-1.wiki and verify correct operation of the file-age computation. 
- Verify correct name-change tracking behavior (no net changes) for: - fossil test-name-changes --debug b120bc8b262ac 374920b20944b 
- Compile for all of the following platforms: - Linux x86
- Linux x86_64
- Mac x86
- Mac x86_64
- Windows (mingw)
- Windows (vc++)
- OpenBSD
 
- Run at least one occurrence of the following commands on every platform: - fossil rebuild
- fossil sync
- fossil test-integrity
 
- Run the following commands on Linux and verify no major memory leaks and no run-time errors or warnings (except for the well-known jump on an uninitialized value that occurs within zlib). - valgrind fossil rebuild
- valgrind fossil sync
 
- Inspect all code changes since the previous release, paying particular attention to the following details: - Can a malicious HTTP request cause a buffer overrun.
- Can a malicious HTTP request expose privileged information to unauthorized users.
 
- Use the release candidate version of fossil in production on the http://www.fossil-scm.org/ website for at least 48 hours (without incident) prior to making the release official. 
- Verify that the Change Log is correct and up-to-date. 
Upon successful completion of all tests above, tag the release candidate with the "release" tag and set its background color to "#d0c0ff". Update the www/changes.wiki file to show the date of the release.