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

1. From within a checkout of the Fossil tree, display this file with the command "fossil ui --page doc/ckout/test/release-checklist.wiki". That is the only way the links below will work.

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

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

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

   1. Also view the same check-ins on a /timeline view by clicking on the date for each check-in in the /info view, as the graph rendering is slightly different.

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

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

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

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

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

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

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

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

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

    Achtung: make sure to point valgrind to the proper fossil binary so that it does not pick up another from the PATH.

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

13. Use the release candidate version of fossil in production on the http://fossil-scm.org/ website for at least 48 hours (without incident) prior to making the release official.

14. Verify that the minimum SQLite version requirement is up-to-date:

    1. Check the version number in the line starting "define MINIMUM_SQLITE_VERSION" near the top of auto.def
    2. Check the output of ./configure --print-minimum-sqlite-version

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