<title>Release Checklist</title>
This file describes the testing procedures for Fossil prior to an
official release.
<ol>
<li><p>
From within a checkout of the Fossil tree, display this file with
the command "<b>fossil ui --page doc/ckout/test/release-checklist.wiki</b>".
That is the only way the links below will work.
<li><p>
From a private directory (not the source tree) run
"<b>tclsh $SRC/test/tester.tcl $FOSSIL</b>" where $FOSSIL is the
name of the executable under test and $SRC is the source tree.
Verify that there are no errors.
<li><p>
Click on each of the links in in the
[./graph-test-1.wiki] document and verify that all graphs are
rendered correctly.
<li><p>
Click on each of the links in in the
[./graph-test-2.md] document and verify that all graphs are
rendered correctly.
<ol type="a">
<li> 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.
</ol>
<li><p>
Click on each of the links in in the
[./diff-test-1.wiki] document and verify that all diffs are
rendered correctly.
<li><p>
Click on the following link to verify that it works: [./test-page%2b%2b.wiki | ./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".)
<li><p>
Shift-click on each of the links in [./fileage-test-1.wiki] and verify
correct operation of the file-age computation.
<li><p>
Verify correct name-change tracking behavior (no net changes) for:
<blockquote><b>
fossil test-name-changes --debug b120bc8b262ac 374920b20944b
</b></blockquote>
<li><p>
Compile for all of the following platforms:
<ol type="a">
<li> Linux x86
<li> Linux x86_64
<li> Mac x86
<li> Mac x86_64
<li> Windows (mingw)
<li> Windows (vc++)
<li> OpenBSD
</ol>
<li><p>
Run at least one occurrence of the following commands on every
platform:
<ol type="a">
<li> <b>fossil rebuild</b>
<li> <b>fossil sync</b>
<li> <b>fossil test-integrity</b>
</ol>
<li><p>
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).</p>
<ol type="a">
<li> <b>valgrind fossil rebuild</b>
<li> <b>valgrind fossil sync</b>
</ol>
<p>Achtung: make sure to point valgrind to the proper fossil binary
so that it does not pick up another from the PATH.</p>
<li><p>
Inspect [http://fossil-scm.org/home/vdiff?from=release&to=trunk&sbs=1|all code changes since the previous release], paying particular
attention to the following details:
<ol type="a">
<li> Can a malicious HTTP request cause a buffer overrun.
<li> Can a malicious HTTP request expose privileged information to
unauthorized users.
</ol>
<li><p>
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.
<li><p>
Verify that the minimum SQLite version requirement is up-to-date:
<ol type="a">
<li> Check the version number in the line starting "define MINIMUM_SQLITE_VERSION" near the top of [/file?name=auto.def&ci=tip | auto.def]
<li> Check the output of <b>./configure --print-minimum-sqlite-version</b>
</ol>
<li><p>
Verify that the [../www/changes.wiki | Change Log] is correct and
up-to-date.
</ol>
<hr>
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.