Fossil SCM

Release Checklist

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](/test/test-page%2b%2b.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](http://fossil-scm.org/home/vdiff?from=release&to;=trunk&sbs;=1), 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](/file?name=auto.def&ci;=tip)
    2. Check the output of ./configure --print-minimum-sqlite-version

15. Verify that the [Change Log](/test/../www/changes.wiki) 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.