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 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
• Extra patches can be included in this branch
• Source packages are created from this branch. See QtWebKitPackaging for details and instructions for producing packages.

Getting changes into the 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).

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

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.