1 To make a release of Weston and/or Wayland, follow these steps.
3 0. Verify the test suites and codebase checks pass. All of the
4 tests pass should either pass or skip.
8 1. Update the first three lines of configure.ac to the intended
9 version, commit. Also note that Weston includes versioned
10 dependencies on 'wayland-server' and 'wayland-client' in
11 configure.ac which typically need updated as well. Then commit
14 $ export RELEASE_NUMBER="x.y.z"
15 $ export RELEASE_NAME="[alpha|RC1|RC2|official|point]"
17 $ git commit configure.ac -m "configure.ac: bump to version $RELEASE_NUMBER for the $RELEASE_NAME release"
20 2. For Weston releases, install Xwayland, either from your distro or
21 manually (see http://wayland.freedesktop.org/building.html). If
22 you install it to a location other than /usr/bin/Xwayland, specify
23 this in the following env var:
25 export DISTCHECK_CONFIGURE_FLAGS="--with-xserver-path=<your-Xwayland-path>"
27 If you're using a locally installed libinput or other dependency
28 libraries, you'll likely need to set a few other environment
31 export WLD="<path-to-your-local-installation>"
32 export LD_LIBRARY_PATH=$WLD/lib
33 export PKG_CONFIG_PATH=$WLD/lib/pkgconfig:$WLD/share/pkgconfig/
35 3. Run the release.sh script to generate the tarballs, sign and
36 upload them, and generate a release announcement template.
37 This script can be obtained from X.org's modular package:
39 http://cgit.freedesktop.org/xorg/util/modular/tree/release.sh
41 The script supports a --dry-run option to test it without actually
42 doing a release. If the script fails on the distcheck step due to
43 a testsuite error that can't be fixed for some reason, you can
44 skip testsuite by specifying the --dist argument. Pass --help to
45 see other supported options.
49 For wayland, also publish the publican documentation to
50 wayland.freedesktop.org:
55 4. Compose the release announcements. The script will generate
56 *.x.y.0.announce files with a list of changes and tags, one for
57 wayland, one for weston. Prepend these with a human-readable
58 listing of the most notable changes. For x.y.0 releases, indicate
59 the schedule for the x.y+1.0 release.
61 5. Send the release announcements to
62 wayland-devel@lists.freedesktop.org
64 6. Get your freshly posted release email URL from
65 http://lists.freedesktop.org/archives/wayland-devel/
67 7. Update releases.html in wayland-web with links to tarballs and
68 the release email URL.
70 The register_release script in wayland-web will generate an HTML
71 snippet that can be pasted into releases.html (or e.g. in emacs
72 insert it via "C-u M-! register_release x.y.z RC2") and
77 $ git commit ./releases.html -m "Add ${RELEASE_NUMBER} release"
81 8. Update topic in #wayland to point to the release announcement URL
83 For x.y.0 releases, also create the release series x.y branch. The x.y
84 branch is for bug fixes and conservative changes to the x.y.0 release,
85 and is where we release x.y.z releases from. Creating the x.y branch
86 opens up master for new development and lets new development move on.
87 We've done this both after the x.y.0 release (to focus development on
88 bug fixing for the x.y.1 release for a little longer) or before the
89 x.y.0 release (like we did with the 1.5.0 release, to unblock master
95 The master branch configure.ac version should always be (at least)
96 x.y.90, with x.y being the most recent stable branch. Stable branch
97 configure version is just whatever was most recently released from
100 For stable branches, we commit fixes to master first, then cherry-pick
101 them back to the stable branch.