Fossil

This file describes the testing procedures for Fossil prior to an official release.

1. 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.

2. Click on each of the links in in the ./graph-test-1.wiki document and verify that all graphs are rendered correctly.

3. Click on each of the links in in the ./diff-test-1.wiki document and verify that all diffs are rendered correctly.

4. 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".)

5. Shift-click on each of the links in ./fileage-test-1.wiki and verify correct operation of the file-age computation.

6. Verify correct name-change tracking behavior (no net changes) for:

   fossil test-name-changes --debug b120bc8b262ac 374920b20944b

7. Compile for all of the following platforms:

   1. Linux x86
   2. Linux x86_64
   3. Mac x86
   4. Mac x86_64
   5. Windows (mingw)
   6. Windows (vc++)
   7. OpenBSD

8. Run at least one occurrence of the following commands on every platform:

   1. fossil rebuild
   2. fossil sync
   3. fossil test-integrity

9. 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).

   1. valgrind fossil rebuild
   2. valgrind fossil sync

10. Inspect all code changes since the previous release, paying particular attention to the following details:

    1. Can a malicious HTTP request cause a buffer overrun.
    2. Can a malicious HTTP request expose privileged information to unauthorized users.

11. 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.

12. 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.