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
15 $ git commit configure.ac -m "configure.ac: bump to version x.y.z for the xxx release"
18 2. For Weston releases, install Xwayland, either from your distro or
19 manually (see http://wayland.freedesktop.org/building.html). If
20 you install it to a location other than /usr/bin/Xwayland, specify
21 this in the following env var:
23 export DISTCHECK_CONFIGURE_FLAGS="--with-xserver-path=<your-Xwayland-path>"
25 3. Run the release.sh script to generate the tarballs, sign and
26 upload them, and generate a release announcement template.
27 This script can be obtained from X.org's modular package:
29 http://cgit.freedesktop.org/xorg/util/modular/tree/release.sh
31 The script supports a --dry-run option to test it without actually
32 doing a release. If the script fails on the distcheck step due to
33 a testsuite error that can't be fixed for some reason, you can
34 skip testsuite by specifying the --dist argument. Pass --help to
35 see other supported options.
37 4. Compose the release announcements. The script will generate
38 *.x.y.0.announce files with a list of changes and tags, one for
39 wayland, one for weston. Prepend these with a human-readable
40 listing of the most notable changes. For x.y.0 releases, indicate
41 the schedule for the x.y+1.0 release.
43 5. Send the release announcements to
44 wayland-devel@lists.freedesktop.org
46 6. Get your freshly posted release email URL from
47 http://lists.freedesktop.org/archives/wayland-devel/
49 7. Update releases.html in wayland-web with links to tarballs and
50 the release email URL.
52 $ git commit releases.html -m "Add x.y.z release"
54 $ rsync -avz * wayland.freedesktop.org:/srv/wayland.freedesktop.org/www/
56 8. Update topic in #wayland to point to the release announcement URL
59 For x.y.0 releases, also create the x.y branch. The x.y branch is for
60 bug fixes and conservative changes to the x.y.0 release, and is where
61 we release x.y.z releases from. Creating the x.y branch opens up
62 master for new development and lets new development move on. We've
63 done this both after the x.y.0 release (to focus development on bug
64 fixing for the x.y.1 release for a little longer) or before the x.y.0
65 release (like we did with the 1.5.0 release, to unblock master
71 The master branch configure.ac version should always be (at least)
72 x.y.90, with x.y being the most recent stable branch. Stable branch
73 configure version is just whatever was most recently released from
76 For stable branches, we commit fixes to master first, then cherry-pick
77 them back to the stable branch.