⚠ Archived content — this site is no longer maintained.   Current WebKit documentation is at docs.webkit.org.
wiki:QtWebKitReleases

Version 21 (modified by Ademar Reis, 15 years ago) ( diff )

--

  1. Procedures and policies for releases of QtWebKit
    1. Release branches and their status
      1. QtWebKit 2.2
      2. QtWebKit 2.1.x
      3. QtWebKit 2.1
      4. QtWebKit 2.0
    2. Release branch creation
    3. Getting changes into a release branch
    4. Procedures for cherry-picking and weekly releasing
    5. Release Management Tools

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

Status: branch open, under stabilization

QtWebKit 2.1.x

Status: open (next update on top of 2.1, will include html5 media)

QtWebKit 2.1

Status: ​2.1.0 released on Apr 18, 2011

QtWebKit 2.0

Status: 2.0.0 released as part of Qt-4.7, maintenance

Release branch creation

Getting changes into a release branch

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

  • Fix data corruption
  • Fix crashes
  • Fix a previously broken build
  • Regression from the last minor release
  • Documentation changes
  • Crucial usability issue (after discussion in the mailing list)

There are two ways to integrate changes into a release branch:

  • 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;
  • The changes are public and live on a gitorious branch, rebased with the targeted release;
  • 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 marked to block the tracker bug for patches pending trunk inclusion: ​https://bugs.webkit.org/show_bug.cgi?id=32653;
  • Any exception has to be first discussed in the public mailing list;

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.

Procedures for cherry-picking and weekly releasing

The process for cherry-picking changes from trunk to a stable branch is semi-automated. To keep things working as expected, some care must be taken when commiting changes there. Below are the basic steps and the commands involved:

  • Clone the ​qtwebkit git/svn mirror and keep it up to date;
  • Downloand and setup ​qtwebkit/tools (change PATH and PYTHONPATH as necessary);
  • Check UsingGitWithWebKit for valuable tips and tricks;
  • Set your username and password in git-config (see instructions in the link above);
  • From the branch where you want to cherry-pick a change (git new-workdir is your friend), run cherry-pick-into-release-branch.py (see --help). This script will parse bugzilla, ask for cherry-picks, add comments and remove bugs from their trackers;
  • If there's a conflict, the script will abort. In that case:
    • Solve the conflict (git status, git rm, git add, patch the files manually, etc -- your choice);
    • Commit the changes, keeping the original changelog from the original git commit;
    • Run the script again, it'll detect the new commit and continue as expected.
  • Before letting the script add a comment to bugzilla, make sure the build is not broken and run some basic tests (run QtTestBrowser, the API tests -- your choice), so that if there's something broken, you can fix it and git commit --amend the changes before a reference is added to bugzilla.
  • Avoid adding extra commits in the branch, always prefer cherry-picks to keep cross references with what's in trunk.
  • If the patch is a backport, you're free to add your own changelog, but make sure there are at least two lines there: one with the bug title and one with the full bug URL;
  • In case of doubts, follow the example of what's already there (see git log).

To create release notes reports (similiar to the ones posted weekly in the ​QtWebKit Developer Journal), run the create-release-notes.py (see --help). Usually it looks like this: 

  $ create-release-notes.py --commits <previous-tag> --email 'foo@bar.com;bar@foo.com'

Don't forget to tag the repository (and git push --tags) before making an announcement.

Release Management Tools

The scripts used to semi-automate the release management work (cherry-pick, bugzilla interaction, reports, release-notes, etc) can be found in the ​qtwebkit/tools git repository.

Note: See TracWiki for help on using the wiki.