configure.ac: bump to version 1.7.93 for the RC2 release
[platform/upstream/weston.git] / releasing.txt
1 To make a release of Weston and/or Wayland, follow these steps.
2
3   0.  Verify the test suites and codebase checks pass.  All of the
4       tests pass should either pass or skip.
5
6       $ make check
7
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
12       your changes:
13
14           $ export RELEASE_NUMBER="x.y.z"
15           $ export RELEASE_NAME="[alpha|RC1|RC2|official|point]"
16       $ git status
17       $ git commit configure.ac -m "configure.ac: bump to version $RELEASE_NUMBER for the $RELEASE_NAME release"
18       $ git push
19
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:
24
25       export DISTCHECK_CONFIGURE_FLAGS="--with-xserver-path=<your-Xwayland-path>"
26
27       If you're using a locally installed libinput or other dependency
28       libraries, you'll likely need to set a few other environment
29       variables:
30
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/
34
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:
38
39         http://cgit.freedesktop.org/xorg/util/modular/tree/release.sh
40
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.
46
47           $ release.sh .
48
49   4.  Compose the release announcements.  The script will generate
50       *.x.y.0.announce files with a list of changes and tags, one for
51       wayland, one for weston.  Prepend these with a human-readable
52       listing of the most notable changes.  For x.y.0 releases, indicate
53       the schedule for the x.y+1.0 release.
54
55   5.  Send the release announcements to
56       wayland-devel@lists.freedesktop.org
57
58   6.  Get your freshly posted release email URL from
59       http://lists.freedesktop.org/archives/wayland-devel/
60
61   7.  Update releases.html in wayland-web with links to tarballs and
62       the release email URL.
63
64       $ git commit releases.html -m "Add x.y.z release"
65       $ git push
66       $ rsync -avz * wayland.freedesktop.org:/srv/wayland.freedesktop.org/www/
67
68   8.  Update topic in #wayland to point to the release announcement URL
69
70
71 For x.y.0 releases, also create the x.y branch.  The x.y branch is for
72 bug fixes and conservative changes to the x.y.0 release, and is where
73 we release x.y.z releases from.  Creating the x.y branch opens up
74 master for new development and lets new development move on.  We've
75 done this both after the x.y.0 release (to focus development on bug
76 fixing for the x.y.1 release for a little longer) or before the x.y.0
77 release (like we did with the 1.5.0 release, to unblock master
78 development early). 
79
80     $ git branch x.y
81     $ git push origin x.y
82
83 The master branch configure.ac version should always be (at least)
84 x.y.90, with x.y being the most recent stable branch.  Stable branch
85 configure version is just whatever was most recently released from
86 that branch.
87
88 For stable branches, we commit fixes to master first, then cherry-pick
89 them back to the stable branch.