Making a release of WebKitGTK

This document describes the steps toward making a release. To understand release strategy and timing please see ​https://trac.webkit.org/wiki/WebKitGTKStableReleases

1. The last commit before release

• Once per release cycle, update hardcoded Chrome, Safari and OS X version strings in ​UserAgentGtk.cpp.
• Update the ​NEWS file using the same format as the previous entry.
  • Identify the commit id of the previous release (NEWS file is normally changed only when releasing, so you could get the commit id of the previous release by looking at NEWS history)
  • Summarize major changes briefly in a style similar to other entries in NEWS.
  • You can use ​gtk-release-notes script.
    • Copy the script to Tools/Scripts and run it giving the commit id of the previous release.
    • It returns a list of bugs fixed since the given revision that might be related to the GTK port and the list fo people who fixed every bug.
  • Take special care to note any additions in the API.
• Update ​Source/cmake/OptionsGTK.cmake:
  • The public version is controlled by the line:

    SET_PROJECT_VERSION(2 22 3)
    

  • The ​libtool library version is controlled by the lines:

    CALCULATE_LIBRARY_VERSIONS_FROM_LIBTOOL_TRIPLE(WEBKIT2 C R A)
    CALCULATE_LIBRARY_VERSIONS_FROM_LIBTOOL_TRIPLE(JAVASCRIPTCORE C R A)
    

    • C (current): increment if the interface has additions, changes, removals.
    • R (revision): increment any time the source changes; set to 0 if you increment CURRENT
    • A (age): increment if any interfaces have been added; set to 0 if any interfaces have been changed or removed. Removal has precedence over adding, so set to 0 if both happened.

2. Run final tests before release

• Generate the HTML documentation

  WebKitBuild/Release $ ../../Tools/gtk/generate-gtkdoc
  

• Run ​make-dist script with the -c option to ensure a clean build is done

  WebKitBuild/Release $ export MAKE_ARGS=-j16
  WebKitBuild/Release $ ../../Tools/gtk/make-dist -c -s ../../ ./manifest.txt
  

• Check that the bots are not horribly broken and run the layout tests locally and see that they are in reasonably good health
• Commit the changes to NEWS and configure.ac. It's especially important to mention the new version number in your commit message.

3. Make the release

• ​make-dist should have created tarball in the build directory. Compress it with xz:

  WebKitBuild/Release $ xz -f webkitgtk-X.Y.Z.tar
  

• Update or clone the ​webkitgtk.org repository and run webkit-release script with the new tarball

  ./webkit-release release --host=<host-to-upload-the-tarball> webkitgtk-X.Y.Z.tar.xz
  

• Check the commit generated by webkit-release script and push it.
• Tag the release using the command:

  svn cp http://svn.webkit.org/repository/webkit/trunk/  http://svn.webkit.org/repository/webkit/releases/WebKitGTK/webkit-[release version]
  

4. After the release

• Send a message to announce the new release to ​webkit-gtk@lists.webkit.org with CC: ​gnome-announce-list@gnome.org if you didn't use the -n option of webkit-release script, you can copy and paste the text announcement from the webkit-release output.
• Update the WebKitGTK entry of the current moduleset in the following git.gnome.org repositories:
  • gnome-build-meta repository (master branch or latest stable branch)
  • gnome-sdk-images repository (master branch or latest stable branch). (Note this repository will be obsoleted by gnome-build-meta in the future.)
  • gnome-continuous repository (master branch only). (Note this repository will be obsoleted by gnome-build-meta in the future.)
• Update the IRC topic message
• Update WebKitGTK if needed.
• Update WebKitGTK/StartHacking if needed.