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