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       $ git status
  15       $ git commit configure.ac -m "configure.ac: bump to version x.y.z for the xxx release"
  16       $ git push
  17
  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:
  22
  23       export DISTCHECK_CONFIGURE_FLAGS="--with-xserver-path=<your-Xwayland-path>"
  24
  25       If you're using a locally installed libinput or other dependency
  26       libraries, you'll likely need to set a few other environment
  27       variables:
  28
  29       export WLD="<path-to-your-local-installation>"
  30       export LD_LIBRARY_PATH=$WLD/lib
  31       export PKG_CONFIG_PATH=$WLD/lib/pkgconfig:$WLD/share/pkgconfig/
  32
  33   3.  Run the release.sh script to generate the tarballs, sign and
  34       upload them, and generate a release announcement template.
  35       This script can be obtained from X.org's modular package:
  36
  37         http://cgit.freedesktop.org/xorg/util/modular/tree/release.sh
  38
  39       The script supports a --dry-run option to test it without actually
  40       doing a release.  If the script fails on the distcheck step due to
  41       a testsuite error that can't be fixed for some reason, you can
  42       skip testsuite by specifying the --dist argument.  Pass --help to
  43       see other supported options.
  44
  45   4.  Compose the release announcements.  The script will generate
  46       *.x.y.0.announce files with a list of changes and tags, one for
  47       wayland, one for weston.  Prepend these with a human-readable
  48       listing of the most notable changes.  For x.y.0 releases, indicate
  49       the schedule for the x.y+1.0 release.
  50
  51   5.  Send the release announcements to
  52       wayland-devel@lists.freedesktop.org
  53
  54   6.  Get your freshly posted release email URL from
  55       http://lists.freedesktop.org/archives/wayland-devel/
  56
  57   7.  Update releases.html in wayland-web with links to tarballs and
  58       the release email URL.
  59
  60       $ git commit releases.html -m "Add x.y.z release"
  61       $ git push
  62       $ rsync -avz * wayland.freedesktop.org:/srv/wayland.freedesktop.org/www/
  63
  64   8.  Update topic in #wayland to point to the release announcement URL
  65
  66
  67 For x.y.0 releases, also create the x.y branch.  The x.y branch is for
  68 bug fixes and conservative changes to the x.y.0 release, and is where
  69 we release x.y.z releases from.  Creating the x.y branch opens up
  70 master for new development and lets new development move on.  We've
  71 done this both after the x.y.0 release (to focus development on bug
  72 fixing for the x.y.1 release for a little longer) or before the x.y.0
  73 release (like we did with the 1.5.0 release, to unblock master
  74 development early).
  75
  76     $ git branch x.y
  77     $ git push origin x.y
  78
  79 The master branch configure.ac version should always be (at least)
  80 x.y.90, with x.y being the most recent stable branch.  Stable branch
  81 configure version is just whatever was most recently released from
  82 that branch.
  83
  84 For stable branches, we commit fixes to master first, then cherry-pick
  85 them back to the stable branch.