Procedures and policies for releases of QtWebKit

Releases of QtWebKit are cut from WebKit's trunk. Some time before the release a new branch is created and hosted in a Git repository. After the release it becomes a maintenance branch.

Release branches and their status

QtWebKit 2.0

Status: released, maintainance

• Tracker bug for critical fixes: ​https://bugs.webkit.org/show_bug.cgi?id=35784

QtWebKit 2.1

Status: open, frozen (critical fixes only)

• Tracker bug for critical fixes: ​https://bugs.webkit.org/show_bug.cgi?id=39121
• Tracker bug for candidate fixes: ​https://bugs.webkit.org/show_bug.cgi?id=44677

Release branch creation

• The release branch is hosted at ​http://gitorious.org/+qtwebkit-developers/webkit/qtwebkit
• It is created off the master branch at ​http://gitorious.org/webkit
• Source packages are created from this branch. See QtWebKitPackaging for details and instructions for producing packages.

Getting changes into a release branch

After the release branch has been created there are two ways to integrate changes:

• The commit is landed in the trunk and then it is cherry-picked into the release branch.
• Time constraints prevent us from landing the patch and we have to include a change before landing it (exceptional patch, see below).

Exceptional patches must satisfy the following criteria before they are included in the release:

• An entry with the attached patch is filed in bugs.webkit.org (using ​http://webkit.org/new-qtwebkit-bug ).
• The patch has a ChangeLog entry.
• Patches that affect the API:
  • A unit test included needs to be included.
  • The API needs to be private, unless there's a concensus that the API is final, reviewed and will land unchanged in the trunk.
• Patches that affect WebCore should have a layout test included, although this is not mandatory.
• At least one WebKit reviewer signs off on the patch and no other reviewer objects.
• The bug is linked from it's corresponding JIRA item at ​http://bugreports.qt.nokia.com/browse/QTWEBKIT
• The bug is marked to block the tracker bug for patches pending trunk inclusion: ​https://bugs.webkit.org/show_bug.cgi?id=32653

After the release we have to make a concentrated effort in reducing the number of exceptional patches, by reviewing the changes in the bugs that the tracker bug (32653) depends on.

Cherry-picking changes into the release branch

If you'd like to include a patch in the release branch, please consider only fixes that

• fix data corruption
• fix crashes
• fixes a previously broken build
• regression from the last minor release
• documentation changes
• crucial usability issue (after discussion the mailing list)

The separate Backporting Fixes page tracks the changes to include, both changes from the trunk as well as exceptional patches.

Proposal for release testing

The idea for a new release would be that it has no regressions over the previous release. This should mean:

• All LayoutTests that passed on the old version should pass on the release candidate.

This can be realized by either storing the list of tests ran on the old release somewhere or using the LayoutTests/ directory of the old release. This has the possible problem that DRT was changed in a incompatible way or the WebKit behavior was changed and now a test would fail. Alternatively one could compare the list of tests that were ran and for every removed test it may not be in the Skipped list.

• It should pass all manual tests.

This can be realized by creating a "meta" manual page linking to all manual tests we want to run before the release.

• It should not consume more memory on the existing test cases and benchmarks.

This can be realized by using libmemusage.so and use QtLauncher on a list of URLs and use mirrored content (from the benchmarking). Afterwards one can manually compare the memory usage.

• Survive a night with iexploder or other fuzzing utilities.

As part of the release the tester(s) should write a simple protocol. It should include the LayoutTests ran, the manual tests ran and their results, the result of libmemusage.so and should be stored on a publicly available place for future reference.

Nokia Releases

Nokia creates the following official releases of QtWebKit:

1. Every releases consists of a source package that is available for download (todo: add location). The source package can be compiled and installed into an existing installation of Qt, as an convenient way for developers to try out new releases with their applications.
2. QtWebKit releases are included in the Qt application and UI framework and can be downloaded as source and binaries from ​http://qt.nokia.com/. Qt's support team provides commercial support for these releases.
3. Nokia also delivers the QtWebKit releases to the Symbian Foundation and the Maemo project.

In these release channels the release is always first available as a source only package. New releases will be included in future versions of Qt. It may happen that a release becomes available in Symbian or Maemo before it is included in Qt, as these delivery channels are independent. The inclusion of newer QtWebKit releases in Symbian and Maemo and their availability as separate source packages constitutes the independence from Qt.

We maintain backwards binary and source compatibility between minor and patch releases.