diff --git a/releasing.md b/releasing.md new file mode 100644 index 00000000..1864dc33 --- /dev/null +++ b/releasing.md @@ -0,0 +1,72 @@ +# Releasing + +To make a release of Weston, follow these steps. + +0. Verify the test suites and codebase checks pass. All of the tests should + either pass or skip. + + ninja -C build/ test + +1. Verify that the wayland and wayland-protocols version dependencies are + correct, and that wayland-protocols has had a release with any needed + protocol updates. + +2. Update the first stanza of `meson.build` to the intended version. + + If the ABI has been broken, make sure `libweston_major` has been bumped since + the last release. + + Then commit your changes: + + RELEASE_NUMBER="x.y.z" + RELEASE_NAME="[alpha|beta|RC1|RC2|official|point]" + git status + git commit meson.build -m "build: bump to version $RELEASE_NUMBER for the $RELEASE_NAME release" + git push + +3. Run the `release.sh` script to generate the tarballs, sign and upload them, + and generate a release announcement template. This script can be obtained + from X.org's modular package: + + https://gitlab.freedesktop.org/xorg/util/modular/blob/master/release.sh + + The script supports a `--dry-run` option to test it without actually doing a + release. If the script fails on the distcheck step due to a test suite error + that can't be fixed for some reason, you can skip testsuite by specifying + the `--dist` argument. Pass `--help` to see other supported options. + + release.sh . + +5. Compose the release announcements. The script will generate *.x.y.z.announce + files with a list of changes and tags. Prepend these with a human-readable + listing of the most notable changes. For x.y.0 releases, indicate the + schedule for the x.y+1.0 release. + +6. PGP sign the release announcement and send it to + . + +7. Update `releases.html` in wayland.freedesktop.org with links to tarballs and + the release email URL. Copy tarballs produced by `release.sh` to `releases/`. + + Once satisfied: + + git commit -am "releases: add ${RELEASE_NUMBER} release" + git push + +For x.y.0 releases, also create the release series x.y branch. The x.y branch +is for bug fixes and conservative changes to the x.y.0 release, and is where we +create x.y.z releases from. Creating the x.y branch opens up master for new +development and lets new development move on. We've done this both after the +x.y.0 release (to focus development on bug fixing for the x.y.1 release for a +little longer) or before the x.y.0 release (like we did with the 1.5.0 release, +to unblock master development early). + + git branch x.y [sha] + git push origin x.y + +The master branch's `meson.build` version should always be (at least) x.y.90, +with x.y being the most recent stable branch. The stable branch's `meson.build` +version is just whatever was most recently released from that branch. + +For stable branches, we commit fixes to master first, then `git cherry-pick -x` +them back to the stable branch. diff --git a/releasing.txt b/releasing.txt deleted file mode 100644 index 446e1ad4..00000000 --- a/releasing.txt +++ /dev/null @@ -1,113 +0,0 @@ -To make a release of Weston and/or Wayland, follow these steps. - - 0. Verify the test suites and codebase checks pass. All of the - tests should either pass or skip. - - $ make check - - 1. For Weston, verify that the wayland and wayland-protocols version - dependencies are correct, and that wayland-protocols has had a - release with any needed protocol updates. - - 2. Update the first stanza of configure.ac to the intended versions - for Weston and libweston. - - For Weston's x.y.0 releases, if libweston_major_version is greater than - weston_major_version, bump the Weston version numbers (major, minor, - micro) to match the libweston version numbers (major, minor, patch). - - Additionally for all Weston releases, if libweston's - major.minor.patch version is less than Weston's major.minor.micro - version, bump libweston version numbers to match the Weston - version numbers. - - Weston releases are made with the Weston version number, not with the - libweston version number. - - Then commit your changes: - - $ export RELEASE_NUMBER="x.y.z" - $ export RELEASE_NAME="[alpha|beta|RC1|RC2|official|point]" - $ git status - $ git commit configure.ac -m "configure.ac: bump to version $RELEASE_NUMBER for the $RELEASE_NAME release" - $ git push - - 3. For Weston releases, install Xwayland, either from your distro or - manually (see http://wayland.freedesktop.org/building.html). If - you install it to a location other than /usr/bin/Xwayland, specify - this in the following env var: - - XWAYLAND=$(which Xwayland) # Or specify your own path - export DISTCHECK_CONFIGURE_FLAGS="--with-xserver-path=$XWAYLAND" - - If you're using a locally installed libinput or other dependency - libraries, you'll likely need to set a few other environment - variables: - - export WLD="" - export LD_LIBRARY_PATH=$WLD/lib - export PKG_CONFIG_PATH=$WLD/lib/pkgconfig:$WLD/share/pkgconfig/ - - 4. Run the release.sh script to generate the tarballs, sign and - upload them, and generate a release announcement template. - This script can be obtained from X.org's modular package: - - http://cgit.freedesktop.org/xorg/util/modular/tree/release.sh - - The script supports a --dry-run option to test it without actually - doing a release. If the script fails on the distcheck step due to - a testsuite error that can't be fixed for some reason, you can - skip testsuite by specifying the --dist argument. Pass --help to - see other supported options. - - $ release.sh . - - For Wayland official and point releases, also publish the publican - documentation to wayland.freedesktop.org: - - $ ./publish-doc - - 5. Compose the release announcements. The script will generate - *.x.y.z.announce files with a list of changes and tags, one for - wayland, one for weston. Prepend these with a human-readable - listing of the most notable changes. For x.y.0 releases, indicate - the schedule for the x.y+1.0 release. - - 6. pgp sign the release announcements and send them to - wayland-devel@lists.freedesktop.org - - 7. Update releases.html in wayland-web with links to tarballs and - the release email URL. - - The wl_register_release script in wayland-web will generate an HTML - snippet that can be pasted into releases.html (or e.g. in emacs - insert it via "C-u M-! scripts/wl_register_release x.y.z") and - customized. - - Once satisfied: - - $ git commit ./releases.html -m "releases: Add ${RELEASE_NUMBER} release" - $ git push - $ ./deploy - - 8. Update topic in #wayland to point to the release announcement URL - -For x.y.0 releases, also create the release series x.y branch. The x.y -branch is for bug fixes and conservative changes to the x.y.0 release, -and is where we create x.y.z releases from. Creating the x.y branch -opens up master for new development and lets new development move on. -We've done this both after the x.y.0 release (to focus development on -bug fixing for the x.y.1 release for a little longer) or before the -x.y.0 release (like we did with the 1.5.0 release, to unblock master -development early). - - $ git branch x.y [sha] - $ git push origin x.y - -The master branch's configure.ac version should always be (at least) -x.y.90, with x.y being the most recent stable branch. The stable -branch's configure.ac version is just whatever was most recently -released from that branch. - -For stable branches, we commit fixes to master first, then cherry-pick -them back to the stable branch.