Version 4 (modified by Simon Hausmann, 14 years ago) (diff)


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

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 (using ).
  • 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

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.