1To make a release of Wayland, follow these steps. 2 3 0. Verify the test suites and codebase checks pass. All of the 4 tests should either pass or skip. 5 6 $ make check 7 8 1. Update the first stanza of configure.ac to the intended version. 9 10 Then commit your changes: 11 12 $ export RELEASE_NUMBER="x.y.z" 13 $ export RELEASE_NAME="[alpha|beta|RC1|RC2|official|point]" 14 $ git status 15 $ git commit configure.ac -m "configure.ac: bump to version $RELEASE_NUMBER for the $RELEASE_NAME release" 16 $ git push 17 18 2. Run the release.sh script to generate the tarballs, sign and 19 upload them, and generate a release announcement template. 20 This script can be obtained from X.org's modular package: 21 22 http://cgit.freedesktop.org/xorg/util/modular/tree/release.sh 23 24 The script supports a --dry-run option to test it without actually 25 doing a release. If the script fails on the distcheck step due to 26 a testsuite error that can't be fixed for some reason, you can 27 skip testsuite by specifying the --dist argument. Pass --help to 28 see other supported options. 29 30 $ release.sh . 31 32 For Wayland official and point releases, also publish the publican 33 documentation to wayland.freedesktop.org: 34 35 $ ./publish-doc 36 37 3. Compose the release announcements. The script will generate 38 *.x.y.z.announce files with a list of changes and tags. Prepend 39 it with a human-readable listing of the most notable changes. 40 For x.y.0 releases, indicate the schedule for the x.y+1.0 41 release. 42 43 4. PGP sign the release announcements and send them to 44 wayland-devel@lists.freedesktop.org 45 46 5. Update releases.html in wayland-web with links to tarballs and 47 the release email URL. 48 49 The wl_register_release script in wayland-web will generate an HTML 50 snippet that can be pasted into releases.html (or e.g. in emacs 51 insert it via "C-u M-! scripts/wl_register_release x.y.z") and 52 customized. 53 54 Once satisfied: 55 56 $ git commit ./releases.html -m "releases: Add ${RELEASE_NUMBER} release" 57 $ git push 58 $ ./deploy 59 60For x.y.0 releases, also create the release series x.y branch. The x.y 61branch is for bug fixes and conservative changes to the x.y.0 release, 62and is where we create x.y.z releases from. Creating the x.y branch 63opens up master for new development and lets new development move on. 64We've done this both after the x.y.0 release (to focus development on 65bug fixing for the x.y.1 release for a little longer) or before the 66x.y.0 release (like we did with the 1.5.0 release, to unblock master 67development early). 68 69 $ git branch x.y [sha] 70 $ git push origin x.y 71 72The master branch's configure.ac version should always be (at least) 73x.y.90, with x.y being the most recent stable branch. The stable 74branch's configure.ac version is just whatever was most recently 75released from that branch. 76 77For stable branches, we commit fixes to master first, then cherry-pick 78them back to the stable branch. 79