| 7 | | Configure your WebKit checkout as instructed in https://trac.webkit.org/wiki/UsingGitWithWebKit |
| 8 | | In particular, make sure to follow the instructions from the following sections: |
| 9 | | |
| 10 | | * Commit manually through git-svn directly |
| 11 | | * Checking out Subversion branches |
| 12 | | |
| 13 | | To check out a stable branch, create a local Git branch which tracks the remote |
| 14 | | one you are interested in, and then check it out. For example, for the `webkit-2.26` |
| 15 | | stable release branch: |
| | 7 | Configure your WebKit checkout as instructed in the [wiki:"UsingGitWithWebKit" Using Git with WebKit] page. In particular, make sure to follow the instructions from the following sections: |
| | 8 | |
| | 9 | * Commit Manually Through git-svn Directly |
| | 10 | * Checking out Subversion Branches |
| | 11 | |
| | 12 | To check out a stable branch, create a local Git branch which tracks the remote one you are interested in, and then check it out. For example, for the `webkit-2.26` stable release branch: |
| 24 | | Be careful with this the first time you download the svn branches because it can take a lot of time, prepare the whole thing hour before you want to do the release. |
| 25 | | |
| 26 | | We always use the branches with x.y numbers such as 2.26 to generate the releases, Not the x.y.z ones, such as 2.26.2 (which correspond to the Subversion release “tags”). |
| 27 | | |
| 28 | | == Creating a release branch == |
| | 21 | Be careful because '''the first time you download the Subversion branches this can take a lot of time'''. It is advisable to run this a few hours before working on a release. Incremental fetches will be much faster afterwards. |
| | 22 | |
| | 23 | Note that we always use the branch names with `X.Y` version numbers such as `webkit-2.26` to generate the releases; and not the `X.Y.Z` ones such as `webkit-2.26.2` (which correspond to the Subversion release “tags”). |
| | 24 | |
| | 25 | == Creating a Release Branch == |
| 38 | | * The '''libtool version''' is set to `(C+1, 0, A+1)` *after* the first stable release |
| 39 | | (`x.y+1.0`) has been made from the stable branch. Note that `A` and `R` are the |
| 40 | | values from the stable branch at the time of the `x.y+1.0` release: this bumps |
| 41 | | if “new” API had been added. |
| 42 | | * The package version is immediately set to `x.y+2.0`. |
| 43 | | * In the first unstable release (x.y.1) we update the package version but not the libtool version, since |
| 44 | | we don't really released the x.y.0 version. |
| 45 | | |
| 46 | | You can check more information about this in the [wiki:"WebKitGTK/Releasing" Making a release of WebKit/GTK] |
| 47 | | |
| 48 | | Next sections are creating the commit for the release. |
| | 34 | * The '''libtool version''' is set to `(C+1, 0, A+1)` *after* the first stable release (`x.y+1.0`) has been made from the stable branch. Note that `A` and `R` are the values from the stable branch at the time of the `x.y+1.0` release: this bumps if new API had been added. |
| | 35 | * The '''package version''' is immediately set to `x.y+2.0`. |
| | 36 | * In the first unstable release (x.y.1) we update the '''package version''' (but ''not'' the libtool version), since we don't really released the x.y.0 version. |
| | 37 | |
| | 38 | You can check more information about this in the [wiki:"WebKitGTK/Releasing" Making a release of WebKit/GTK] page. |
| | 39 | |
| | 40 | The next sections explain how to create the commit for the release. |
| 52 | | Edit `Source/cmake/Options{WPE,GTK}.cmake`, change the '''package''' version |
| 53 | | number in the `SET_PROJECT_VERSION()` macro and update the '''libtool soversion''' |
| 54 | | in the `CALCULATE_LIBRARY_VERSIONS_FROM_LIBTOOL_TRIPLE()` one. |
| 55 | | |
| 56 | | Note: There is some discussion of libtool soversions and some more instructions |
| 57 | | for doing releases [https://trac.webkit.org/wiki/WebKitGTK/Releasing here], |
| 58 | | which should probably be merged with this page! |
| | 44 | Edit `Source/cmake/Options{WPE,GTK}.cmake`, change the '''package''' version number in the `SET_PROJECT_VERSION()` macro and update the '''libtool soversion''' in the `CALCULATE_LIBRARY_VERSIONS_FROM_LIBTOOL_TRIPLE()` one. |
| | 45 | |
| | 46 | Note:: There is some discussion of libtool soversions and some more instructions for doing releases [wiki:"WebKitGTK/Releasing" here], which should probably be merged with this page! |
| 73 | | You can also check the changes from GTK's last release changes to use them, a lot of them are for both ports. |
| 74 | | |
| 75 | | Create a local commit with Git containing the edits to the `.cmake` and `NEWS` |
| 76 | | files, then add a WebKit ChangeLog entry indicating that those changes are |
| | 59 | You can also check the changes from GTK's last release changes to use them, a lot of them are for both ports—but be careful to remove from the WPE release notes those entries which only apply to the GTK port if you do this! |
| | 60 | |
| | 61 | Create a local commit with Git containing the edits to the `.cmake` and `NEWS` files, then add a WebKit ChangeLog entry indicating that those changes are |
| 91 | | This is required only for releases done from a stable branch. Note that releases |
| 92 | | with version ≥X.Y.90 are done from the stable branch as well. |
| 93 | | |
| 94 | | Before cutting a new release, we need to check whether there are pending merges to |
| 95 | | impoty into the stable branch. Wiki pages like https://trac.webkit.org/wiki/WebKitGTK/2.26.x |
| | 76 | This is required only for releases done from a stable branch. Note that releases with version ≥X.Y.90 are done from the stable branch as well. |
| | 77 | |
| | 78 | Before cutting a new release, we need to check whether there are pending merges to import into the stable branch. Wiki pages like [wiki:WebKitGTK/2.26.x] |
| 98 | | First, check out and switch to the stable release branch (see above for configuration). |
| 99 | | Then, for each patch listed for merging: |
| 100 | | |
| 101 | | 1. Find the Git commit-id from the Subversion revision, or from any other means (e.g. |
| 102 | | the Git commit log). The command `git svn find-rev <svn-revision> master` can be |
| 103 | | used to find the Git commit-id for commits present in `trunk`. |
| 104 | | |
| 105 | | 2. Cherry-pick the commit, resolving conflicts if needed. As a shortcut, a command |
| 106 | | like `git cherry-pick $(git svn find-rev <svn-revision> master` can be used. |
| 107 | | |
| 108 | | 3. Use `git commit --amend`, prepend the string `Merge rNNN -` to |
| 109 | | the first line, and remove the git-svn information from the last line of the |
| 110 | | commit log. |
| | 81 | First, check out and switch to the stable release branch (see above for configuration). Then, for each patch listed for merging: |
| | 82 | |
| | 83 | 1. Find the Git commit-id from the Subversion revision, or from any other means (e.g. the Git commit log). The command `git svn find-rev <svn-revision> master` can be used to find the Git commit-id for commits present in `trunk`. |
| | 84 | 2. Cherry-pick the commit, resolving conflicts if needed. As a shortcut, a command like `git cherry-pick $(git svn find-rev <svn-revision> master` can be used. |
| | 85 | 3. Use `git commit --amend`, prepend the string `Merge rNNN -` to the first line, and remove the git-svn information from the last line of the commit log. |
| 114 | | In order to make release tarballs, you need the build directory configured with |
| 115 | | the `DEVELOPER_MODE` option enabled: |
| 116 | | |
| 117 | | In order to do this we need a version of libwpe in the paths, we can compile them in a directory, inside jhbuild or install them in the system. |
| | 89 | In order to make release tarballs, you need the build directory configured with the `DEVELOPER_MODE` option enabled. A suitable version of `libwpe` needs to be installed (as it is a build dependency); it could be installed in its own directory (a prefix-installation), inside the JHBuild environment (which can be WebKit's internal one), or installed in the system directories. |
| | 90 | |
| | 91 | To configure with developer mode enabled and generate tarballs, use: |
| 130 | | Once pending merges have been done (if any), edit `Options{WPE,GTK}.cmake` to update |
| 131 | | the version numbers, add the release notes into `Source/WebKit/{wpe,gtk}/NEWS`, and |
| 132 | | make a new local commit using Git. Then push the changes to the branch with |
| 133 | | `git svn dcommit`. |
| 134 | | |
| 135 | | Finally, use `svn cp` to create the release “tag” into the Subversion repository |
| 136 | | (a tag in Subversion is a branch which only has one revision with the state of |
| 137 | | the tree at the time of making the release): |
| | 107 | Once pending merges have been done (if any), edit `Options{WPE,GTK}.cmake` to update the version numbers, add the release notes into `Source/WebKit/{wpe,gtk}/NEWS`, and make a new local commit using Git. Then push the changes to the branch with `git svn dcommit`. |
| | 108 | |
| | 109 | Finally, use `svn cp` to create the release “tag” into the Subversion repository (a tag in Subversion is a branch which only has one revision with the state of the tree at the time of making the release): |
