1# Releasing 2 3To make a release of Weston, follow these steps. 4 50. Verify the test suites and codebase checks pass. All of the tests should 6 either pass or skip. 7 8 ninja -C build/ test 9 101. Verify that the wayland and wayland-protocols version dependencies are 11 correct, and that wayland-protocols has had a release with any needed 12 protocol updates. 13 142. Update the first stanza of `meson.build` to the intended version. 15 16 If the ABI has been broken, make sure `libweston_major` has been bumped since 17 the last release. 18 19 Then commit your changes: 20 21 RELEASE_NUMBER="x.y.z" 22 RELEASE_NAME="[alpha|beta|RC1|RC2|official|point]" 23 git status 24 git commit meson.build -m "build: bump to version $RELEASE_NUMBER for the $RELEASE_NAME release" 25 git push 26 273. Run the `release.sh` script to generate the tarballs, sign and upload them, 28 and generate a release announcement template. This script can be obtained 29 from X.org's modular package: 30 31 https://gitlab.freedesktop.org/xorg/util/modular/blob/master/release.sh 32 33 The script supports a `--dry-run` option to test it without actually doing a 34 release. If the script fails on the distcheck step due to a test suite error 35 that can't be fixed for some reason, you can skip testsuite by specifying 36 the `--dist` argument. Pass `--help` to see other supported options. 37 38 release.sh . 39 405. Compose the release announcements. The script will generate *.x.y.z.announce 41 files with a list of changes and tags. Prepend these with a human-readable 42 listing of the most notable changes. For x.y.0 releases, indicate the 43 schedule for the x.y+1.0 release. 44 456. PGP sign the release announcement and send it to 46 <wayland-devel@lists.freedesktop.org>. 47 487. Update `releases.html` in wayland.freedesktop.org with links to tarballs and 49 the release email URL. Copy tarballs produced by `release.sh` to `releases/`. 50 51 Once satisfied: 52 53 git commit -am "releases: add ${RELEASE_NUMBER} release" 54 git push 55 56For x.y.0 releases, also create the release series x.y branch. The x.y branch 57is for bug fixes and conservative changes to the x.y.0 release, and is where we 58create x.y.z releases from. Creating the x.y branch opens up master for new 59development and lets new development move on. We've done this both after the 60x.y.0 release (to focus development on bug fixing for the x.y.1 release for a 61little longer) or before the x.y.0 release (like we did with the 1.5.0 release, 62to unblock master development early). 63 64 git branch x.y [sha] 65 git push origin x.y 66 67The master branch's `meson.build` version should always be (at least) x.y.90, 68with x.y being the most recent stable branch. The stable branch's `meson.build` 69version is just whatever was most recently released from that branch. 70 71For stable branches, we commit fixes to master first, then `git cherry-pick -x` 72them back to the stable branch. 73