wiki:QtWebKitReleases

  1. Procedures and Policies for Releases of QtWebKit
    1. Release branches
      1. QtWebKit 5.0.x as part of Qt 5.0.x
      2. QtWebKit 2.2
      3. QtWebKit 2.1
      4. QtWebKit 2.0
    2. QtWebKit 5.x release branch creation
    3. QtWebKit 2.x release branch creation
    4. Getting changes into a release branch
    5. QtWebKit 2.x: Procedures for cherry-picking and weekly releasing
    6. Release Criterias and Timeline
      1. Technology Previews (TPs)
      2. Betas
      3. Release Candidate (RC)
      4. Final Release
      5. Minor Update (maintenance)
    7. Supported Platforms
    8. Release Management Tools
    9. See Also

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

QtWebKit 5.0.x as part of Qt 5.0.x

  • Shipping as part of Qt 5.0's essential modules
  • "stable" branch of qt/qtwebkit module in Qt Gerrit accepting critical bug fixes.

QtWebKit 2.2

QtWebKit 2.1

QtWebKit 2.0

QtWebKit 5.x release branch creation

QtWebKit 2.x 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 for:

  • Security related problems
  • Data corruption
  • Crashes
  • Broken build
  • Regression from the previous 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 trunk and then cherry-picked into the release branch. In Qt 5.x that is done through a submission into Qt's Gerrit.
  • Time constraints prevent us from landing the patch and we have to include a change before landing it.

For Qt 5.x, the Gerrit installation of the Qt project is used for the maintenance of the stable and release branches.

Note for Qt Gerrit approvers: When accepting changes into the Gerrit managed branches of QtWebKit, it is your (the approver) responsibility to ensure that ...

  • ... the change is the result of a cherry-pick from a change landed upstream
  • ... the change finds is way into WebKit trunk.

Do not approve changes where it is not clear how the change finds its way into upstream trunk.

QtWebKit 2.x: Procedures for cherry-picking and weekly releasing

The process for cherry-picking changes from trunk to a stable branch is semi-automated with the use of cherry-pick-into-release-branch.py and the use of meta-bugs. To keep things working as expected and help the automation, some care must be taken when commiting changes in the branch. 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 ​UsingMirrorWithGitSvn and UsingGitWithWebKit for setup instructions and 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;
  • You can use --bugs if you want to cherry-pick some specific bugs or work in a different branch (such as a "devel" or "work-in-progress" branch);
  • 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 with a standard git commit command. It'll keep the changelog from the original git commit plus a list of conflicting files, but you'll have to add a line "Author: Foo Bar <​foobar@whatever.com>", otherwise you'll be listed as the commit author;
    • 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, push the changes to a test branch, run the API or layout 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;
  • Sometimes a fix has follow-up commits to rebaseline layout tests or add other minor fixes. You can find them in the git log of trunk. The script won't detect these, but it can be done by looking for the bug ID and the SVN revision (to-do).

Some general tips:

  • You can push the changes to a test branch and ask the bots to build and run the layout tests on it. It's quite useful when making complex changes;
  • Avoid adding extra commits in the branch, always prefer cherry-picks to keep cross references with what's in trunk (via git-svn-id);
  • 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);
  • Avoid too many changes on bugzilla meta-bugs if they won't help the developers: these changes trigger notification e-mails;
  • Check ​this thread about the usage of meta-bugs on the QtWebKit Mailing List.

IMPORTANT: Special care must be taken when handling fixes for security bugs. Please check the QtWebKit Security Page for details and instructions.

To create release notes reports (similiar to the ones posted weekly to the ​QtWebKit Announcement Mailing List), run the create-release-notes.py (see --help). Some examples: 

  ## Be careful: these notes should not include the title of security-related bugs. Run the script from an unprivileged account.
  $ create-release-notes.py --commits <previous-tag> --email 'foo@bar.com;bar@foo.com'
  $ create-release-notes.py --since-last-tag --commits --email webkit-qt@lists.webkit.org --announce

Tag the repository (git tag -a for an annotated tag) and then push the changes (git push --tags).

Release Criterias and Timeline

These are the simplified release criteria. QA criterias and product requirements are not listed here.

Technology Previews (TPs)

A TP release is basically to invite the community to try out new features and provide some initial feedback. It has no major quality guarantees and the decision about when to release it heavily depends on the feeling from the development team.

  • All buildbots should be green;
  • The development team should be relatively confident that basic features work on the reference platform;
  • The code builds and pass through a basic ​smoke test on all Tier 1 platforms;

Betas

A beta release means the software is stabilizing but has known bugs we plan to fix before the release. There may be multiple betas during the development process.

  • We have buildbots running on all Tier 1 platforms and they're green;
  • The QA team has tested the code for regressions against the latest stable release using the same testcases (and bugs have been opened if necessary);
  • QA Team is actively testing the release on Tier 1 platforms and the weekly ratio between critical bugs fixed and critical bugs reported is bigger than 1;
  • The code builds and pass through a basic ​smoke test on all Tier 2 platforms;

Release Candidate (RC)

A RC release is made when we believe the code is ready to ship.

  • There has been at least one beta release;
  • All buildbots are green;
  • There are no critical bugs blocking the release;
  • Reports from QA indicate we're in better shape than the previous official version;
  • We're confident that the software is ready;

Once the first RC is out, no more "nice-to-have" fixes will be accepted and thus the meta bug is closed;

Final Release

The final release is the last RC but with final versioning.

  • At least one week has passed since the last RC release and no critical bugs have been reported;

After the final release, the meta but that tracks critical bugs blocking the release is closed;

Minor Update (maintenance)

A meta-bug for maintenance is open on bugzilla, following the same pattern of the meta-bugs during the stabilization period.

Supported Platforms

There's always one Reference Platform where development and QA is focused and then Tier 1 and Tier 2 platforms, where testing and support criterias vary. The current list of supported platforms is:

Reference Platform:

  • Linux Desktop

Tier 1:

  • Apple Mac OS X 10.6 (Cocoa)
  • Microsoft Windows XP SP3 32-bit
  • Microsoft Windows 7 32 bits

Tier 2:

  • Microsoft Windows Vista 32 bits
  • Apple Mac OS X 10.5 (Cocoa)
  • Symbian (Symbian^3)

Details in the QtWebKitPlatformSupport wiki.

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.

See Also

Last modified 8 years ago Last modified on Jul 1, 2016, 5:01:18 AM
Note: See TracWiki for help on using the wiki.