[[PageOutline]] = 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 * [wiki:QtWebKitRelease22 QtWebKit 2.2 Release Page] * Tracker bug for critical fixes: https://bugs.webkit.org/show_bug.cgi?id=55055 * Tracker bug for candidate fixes: https://bugs.webkit.org/show_bug.cgi?id=55056 * [http://trac.webkit.org/wiki/QtWebKitFeatures22 Internal Release Notes] === QtWebKit 2.1 === '''Status''': 2.1.0 and 2.1.1 released, maintenance * [https://lists.webkit.org/pipermail/webkit-qt/2011-April/001429.html 2.1.0 released on Apr 18, 2011] * [https://lists.webkit.org/pipermail/webkit-qt/2011-May/001571.html 2.1.0 released on May 23, 2011] * [wiki:QtWebKitRelease21 QtWebKit 2.1 Release Page] * [http://trac.webkit.org/wiki/QtWebKitFeatures21 Internal Release Notes] * Tracker bug for candidate fixes (maintenance): [https://bugs.webkit.org/show_bug.cgi?id=59935 Bug 59935] === QtWebKit 2.0 === '''Status''': 2.0.0 released as part of Qt-4.7, maintenance * [http://trac.webkit.org/wiki/QtWebKitTableOfFeatures20 Internal Release Notes] * Tracker bug for candidate fixes (maintenance): [https://bugs.webkit.org/show_bug.cgi?id=35784 Bug 35784] == Release branch creation == * Release branches are hosted at http://gitorious.org/+qtwebkit-developers/webkit/qtwebkit * They're created from the {{{master}}} branch at http://gitorious.org/webkit * Source packages are created from this branch. See [wiki:"QtWebKitPackaging" QtWebKitPackaging] for details and instructions for producing packages. == 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 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; * They should have a layout test included whenever possible; * 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 ([https://bugs.webkit.org/show_bug.cgi?id=32653 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 [http://gitorious.org/webkit/ qtwebkit git/svn mirror] and keep it up to date; * Downloand and setup [http://gitorious.org/qtwebkit/tools qtwebkit/tools] (change PATH and PYTHONPATH as necessary); * Check [wiki: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 [http://www.google.com.br/search?q=qtwebkit+developer+journal QtWebKit Developer Journal]), run the {{{create-release-notes.py}}} (see {{{--help}}}). Usually it looks like this: {{{ $ create-release-notes.py --commits --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 [http://gitorious.org/qtwebkit/tools qtwebkit/tools git repository].