This file describes the testing procedures for Fossil prior to an official release.
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.
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 ./graph-test-2.md document and verify that all graphs are rendered correctly.
- 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.
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++)
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://fossil-scm.org/ website for at least 48 hours (without incident) prior to making the release official.
Verify that the minimum SQLite version requirement is up-to-date:
- Check the version number in the line starting "define MINIMUM_SQLITE_VERSION" near the top of auto.def
- Check the output of ./configure --print-minimum-sqlite-version
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.