Changes between Version 1 and Version 2 of WPE/Releasing


Ignore:
Timestamp:
Nov 8, 2019 4:10:02 PM (4 years ago)
Author:
Adrian Perez de Castro
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • WPE/Releasing

    v1 v2  
    55== Configuring Git to Fetch Stable Branches ==
    66
    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:
     7Configure 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
     12To 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:
    1613
    1714{{{
    … …  
    2219}}}
    2320
    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 ==
     21Be 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
     23Note 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 ==
    2926
    3027In the '''new branch''':
    3128
    32 - The *libtool* version is imported from the `master` branch, and updated accordingly.
    33 - The next package version will be `x.y.9z` (for the release candidates), and the first
    34   stable release will be `x.y+1.0`.
     29- The '''libtool version''' is imported from the `master` branch, and updated accordingly.
     30- The next '''package version''' will be `x.y.9z` (for the release candidates), and the first stable release will be `x.y+1.0`.
    3531
    3632In the '''master branch''':
    3733
    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
     38You can check more information about this in the [wiki:"WebKitGTK/Releasing" Making a release of WebKit/GTK] page.
     39
     40The next sections explain how to create the commit for the release.
    4941
    5042== Updating Version Numbers ==
    5143
    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!
     44Edit `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!
    5947
    6048== Write Release Notes ==
    6149
    62 Release notes for user-visible changes are in “Source/WebKit/{gtk,wpe}/NEWS”
    63 Check the commit logs since the last version and write down the release notes.
    64 An useful command to only have to read commits relevant to the GLib ports is:
     50Release notes for user-visible changes are in `Source/WebKit/{gtk,wpe}/NEWS`. Check the commit logs since the last version and write down the release notes. An useful command to only have to read commits relevant to the GLib ports is:
    6551
    6652{{{
    … …  
    7157We are going to try to automate this task with and script and upstream it in the future, also sharing it with WebKitGTK.
    7258
    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
     59You 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
     61Create 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
    7762unreviewed for a release:
    7863
    … …  
    8974== Merging Patches to the Stable Branch ==
    9075
    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
     76This 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
     78Before 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]
    9679list patches suggested by developers.
    9780
    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.
     81First, 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.
    11186
    11287== Making Release Tarballs ==
    11388
    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.
     89In 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
     91To configure with developer mode enabled and generate tarballs, use:
    11892
    11993{{{
    … …  
    126100}}}
    127101
     102Note that '''after changing version numbers tarballs must be re-created'''!
     103
     104
    128105== Version Numbers & Tagging ==
    129106
    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):
     107Once 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
     109Finally, 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):
    138110
    139111{{{
    … …  
    147119== Release Notes & Announcing ==
    148120
    149 Release announcements are also uploaded to the project web sites, both of which
    150 use [https://jekyllrb.com/ Jekyll] to generate the content from Markdown sources.
    151 Make sure you have it installed to test your changes locally before pushing the
    152 changes to the web sites.
     121Release announcements are also uploaded to the project web sites, both of which use [https://jekyllrb.com/ Jekyll] to generate the content from Markdown sources. Make sure you have it installed to test your changes locally before pushing the changes to the web sites.
    153122
    154123=== WebKitGTK ===