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.  For Weston, verify that the wayland and wayland-protocols version
   9       dependencies are correct, and that wayland-protocols has had a
  10       release with any needed protocol updates.
  11
  12   2.  Update the first three lines of configure.ac to the intended
  13       version, commit.  Then commit your changes:
  14
  15       $ export RELEASE_NUMBER="x.y.z"
  16       $ export RELEASE_NAME="[alpha|beta|RC1|RC2|official|point]"
  17       $ git status
  18       $ git commit configure.ac -m "configure.ac: bump to version $RELEASE_NUMBER for the $RELEASE_NAME release"
  19       $ git push
  20
  21   3.  For Weston releases, install Xwayland, either from your distro or
  22       manually (see http://wayland.freedesktop.org/building.html).  If
  23       you install it to a location other than /usr/bin/Xwayland, specify
  24       this in the following env var:
  25
  26           XWAYLAND=$(which Xwayland)  # Or specify your own path
  27       export DISTCHECK_CONFIGURE_FLAGS="--with-xserver-path=$XWAYLAND"
  28
  29       If you're using a locally installed libinput or other dependency
  30       libraries, you'll likely need to set a few other environment
  31       variables:
  32
  33       export WLD="<path-to-your-local-installation>"
  34       export LD_LIBRARY_PATH=$WLD/lib
  35       export PKG_CONFIG_PATH=$WLD/lib/pkgconfig:$WLD/share/pkgconfig/
  36
  37   4.  Run the release.sh script to generate the tarballs, sign and
  38       upload them, and generate a release announcement template.
  39       This script can be obtained from X.org's modular package:
  40
  41         http://cgit.freedesktop.org/xorg/util/modular/tree/release.sh
  42
  43       The script supports a --dry-run option to test it without actually
  44       doing a release.  If the script fails on the distcheck step due to
  45       a testsuite error that can't be fixed for some reason, you can
  46       skip testsuite by specifying the --dist argument.  Pass --help to
  47       see other supported options.
  48
  49       $ release.sh .
  50
  51       For wayland, also publish the publican documentation to
  52       wayland.freedesktop.org:
  53
  54       $ ./publish-doc
  55
  56
  57   5.  Compose the release announcements.  The script will generate
  58       *.x.y.z.announce files with a list of changes and tags, one for
  59       wayland, one for weston.  Prepend these with a human-readable
  60       listing of the most notable changes.  For x.y.0 releases, indicate
  61       the schedule for the x.y+1.0 release.
  62
  63   6.  pgp sign the the release announcements and send them to
  64       wayland-devel@lists.freedesktop.org
  65
  66   7.  Update releases.html in wayland-web with links to tarballs and
  67       the release email URL.
  68
  69       The wl_register_release script in wayland-web will generate an HTML
  70       snippet that can be pasted into releases.html (or e.g. in emacs
  71       insert it via "C-u M-! scripts/wl_register_release x.y.z") and
  72       customized.
  73
  74       Once satisfied:
  75
  76       $ git commit ./releases.html -m "releases: Add ${RELEASE_NUMBER} release"
  77       $ git push
  78       $ ./deploy
  79
  80   8.  Update topic in #wayland to point to the release announcement URL
  81
  82 For x.y.0 releases, also create the release series x.y branch.  The x.y
  83 branch is for bug fixes and conservative changes to the x.y.0 release,
  84 and is where we release x.y.z releases from.  Creating the x.y branch
  85 opens up master for new development and lets new development move on.
  86 We've done this both after the x.y.0 release (to focus development on
  87 bug fixing for the x.y.1 release for a little longer) or before the
  88 x.y.0 release (like we did with the 1.5.0 release, to unblock master
  89 development early).
  90
  91     $ git branch x.y
  92     $ git push origin x.y
  93
  94 The master branch configure.ac version should always be (at least)
  95 x.y.90, with x.y being the most recent stable branch.  Stable branch
  96 configure version is just whatever was most recently released from
  97 that branch.
  98
  99 For stable branches, we commit fixes to master first, then cherry-pick
 100 them back to the stable branch.