• Home
  • Line#
  • Scopes#
  • Navigate#
  • Raw
  • Download
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      $ ninja -C build/ test
7
8  1.  Update the first stanza of meson.build 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 meson.build -m "build: 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
21  3.  Compose the release announcements.  The script will generate a
22      wayland-x.y.z-announce.eml file with a list of changes and tags.
23      Prepend it with a human-readable listing of the most notable
24      changes. For x.y.0 releases, indicate the schedule for the x.y+1.0
25      release.
26
27  4.  PGP sign the release announcements and send them to
28      wayland-devel@lists.freedesktop.org
29
30  5.  Update releases.html in wayland-web with links to tarballs and
31      the release email URL.
32
33      The wl_register_release script in wayland-web will generate an HTML
34      snippet that can be pasted into releases.html (or e.g. in emacs
35      insert it via "C-u M-! scripts/wl_register_release x.y.z") and
36      customized.
37
38      Once satisfied:
39
40      $ git commit ./releases.html -m "releases: Add ${RELEASE_NUMBER} release"
41      $ git push
42      $ ./deploy
43
44For x.y.0 releases, also create the release series x.y branch.  The x.y
45branch is for bug fixes and conservative changes to the x.y.0 release,
46and is where we create x.y.z releases from.  Creating the x.y branch
47opens up master for new development and lets new development move on.
48We've done this both after the x.y.0 release (to focus development on
49bug fixing for the x.y.1 release for a little longer) or before the
50x.y.0 release (like we did with the 1.5.0 release, to unblock master
51development early).
52
53    $ git branch x.y [sha]
54    $ git push origin x.y
55
56The master branch's meson.build version should always be (at least)
57x.y.90, with x.y being the most recent stable branch.  The stable
58branch's meson.build version is just whatever was most recently
59released from that branch.
60
61For stable branches, we commit fixes to master first, then cherry-pick
62them back to the stable branch.
63