Artifact f05433096a91b7d12739d1429744e57ca3d9240a:

• File test/release-checklist.wiki — part of check-in [b00e462ffc] at 2012-08-17 18:14:12 on branch trunk — Fixed a number of "the the" duplications in comments, documentation, and HTML (templates). Left the 17 occurences of same in sqlite.c alone. (user: andreask size: 2216) [more...]

Release Checklist

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. Verify correct name-change tracking behavior (no net changes) for:

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

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

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

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

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

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

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

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