releasing.txt

   1 To 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       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
  60 For x.y.0 releases, also create the release series x.y branch.  The x.y
  61 branch is for bug fixes and conservative changes to the x.y.0 release,
  62 and is where we create x.y.z releases from.  Creating the x.y branch
  63 opens up master for new development and lets new development move on.
  64 We've done this both after the x.y.0 release (to focus development on
  65 bug fixing for the x.y.1 release for a little longer) or before the
  66 x.y.0 release (like we did with the 1.5.0 release, to unblock master
  67 development early).
  68
  69     $ git branch x.y [sha]
  70     $ git push origin x.y
  71
  72 The master branch's meson.build version should always be (at least)
  73 x.y.90, with x.y being the most recent stable branch.  The stable
  74 branch's meson.build version is just whatever was most recently
  75 released from that branch.
  76
  77 For stable branches, we commit fixes to master first, then cherry-pick
  78 them back to the stable branch.