|  |  |  | To make a release of Weston and/or Wayland, follow these steps.
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |   0.  Verify the test suites and codebase checks pass.  All of the
 | 
					
						
							|  |  |  |       tests pass should either pass or skip.
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |       $ make check
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |   1.  Update the first three lines of configure.ac to the intended
 | 
					
						
							|  |  |  |       version, commit.  Also note that Weston includes versioned
 | 
					
						
							|  |  |  |       dependencies on 'wayland-server' and 'wayland-client' in
 | 
					
						
							|  |  |  |       configure.ac which occasionally need updated as well.  Then commit
 | 
					
						
							|  |  |  |       your changes:
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |       $ export RELEASE_NUMBER="x.y.z"
 | 
					
						
							|  |  |  |       $ export RELEASE_NAME="[alpha|beta|RC1|RC2|official|point]"
 | 
					
						
							|  |  |  |       $ git status
 | 
					
						
							|  |  |  |       $ git commit configure.ac -m "configure.ac: bump to version $RELEASE_NUMBER for the $RELEASE_NAME release"
 | 
					
						
							|  |  |  |       $ git push
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |   2.  For Weston releases, install Xwayland, either from your distro or
 | 
					
						
							|  |  |  |       manually (see http://wayland.freedesktop.org/building.html).  If
 | 
					
						
							|  |  |  |       you install it to a location other than /usr/bin/Xwayland, specify
 | 
					
						
							|  |  |  |       this in the following env var:
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | 	  XWAYLAND=$(which Xwayland)  # Or specify your own path
 | 
					
						
							|  |  |  |       export DISTCHECK_CONFIGURE_FLAGS="--with-xserver-path=$XWAYLAND"
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |       If you're using a locally installed libinput or other dependency
 | 
					
						
							|  |  |  |       libraries, you'll likely need to set a few other environment
 | 
					
						
							|  |  |  |       variables:
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |       export WLD="<path-to-your-local-installation>"
 | 
					
						
							|  |  |  |       export LD_LIBRARY_PATH=$WLD/lib
 | 
					
						
							|  |  |  |       export PKG_CONFIG_PATH=$WLD/lib/pkgconfig:$WLD/share/pkgconfig/
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |   3.  Run the release.sh script to generate the tarballs, sign and
 | 
					
						
							|  |  |  |       upload them, and generate a release announcement template.
 | 
					
						
							|  |  |  |       This script can be obtained from X.org's modular package:
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |         http://cgit.freedesktop.org/xorg/util/modular/tree/release.sh
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |       The script supports a --dry-run option to test it without actually
 | 
					
						
							|  |  |  |       doing a release.  If the script fails on the distcheck step due to
 | 
					
						
							|  |  |  |       a testsuite error that can't be fixed for some reason, you can
 | 
					
						
							|  |  |  |       skip testsuite by specifying the --dist argument.  Pass --help to
 | 
					
						
							|  |  |  |       see other supported options.
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |       $ release.sh .
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |       For wayland, also publish the publican documentation to
 | 
					
						
							|  |  |  |       wayland.freedesktop.org:
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |       $ ./publish-doc
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |   4.  Compose the release announcements.  The script will generate
 | 
					
						
							|  |  |  |       *.x.y.0.announce files with a list of changes and tags, one for
 | 
					
						
							|  |  |  |       wayland, one for weston.  Prepend these with a human-readable
 | 
					
						
							|  |  |  |       listing of the most notable changes.  For x.y.0 releases, indicate
 | 
					
						
							|  |  |  |       the schedule for the x.y+1.0 release.
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |   5.  pgp sign the the release announcements and send them to
 | 
					
						
							|  |  |  |       wayland-devel@lists.freedesktop.org
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |   6.  Get your freshly posted release email URL from
 | 
					
						
							|  |  |  |       http://lists.freedesktop.org/archives/wayland-devel/
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |   7.  Update releases.html in wayland-web with links to tarballs and
 | 
					
						
							|  |  |  |       the release email URL.
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |       The register_release script in wayland-web will generate an HTML
 | 
					
						
							|  |  |  |       snippet that can be pasted into releases.html (or e.g. in emacs
 | 
					
						
							|  |  |  |       insert it via "C-u M-! scripts/register_release x.y.z RC2") and
 | 
					
						
							|  |  |  |       customized.
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |       Once satisfied:
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |       $ git commit ./releases.html -m "Add ${RELEASE_NUMBER} release"
 | 
					
						
							|  |  |  |       $ git push
 | 
					
						
							|  |  |  |       $ ./deploy
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |   8.  Update topic in #wayland to point to the release announcement URL
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | For x.y.0 releases, also create the release series x.y branch.  The x.y
 | 
					
						
							|  |  |  | branch is for bug fixes and conservative changes to the x.y.0 release,
 | 
					
						
							|  |  |  | and is where we release x.y.z releases from.  Creating the x.y branch
 | 
					
						
							|  |  |  | opens up master for new development and lets new development move on.
 | 
					
						
							|  |  |  | We've done this both after the x.y.0 release (to focus development on
 | 
					
						
							|  |  |  | bug fixing for the x.y.1 release for a little longer) or before the
 | 
					
						
							|  |  |  | x.y.0 release (like we did with the 1.5.0 release, to unblock master
 | 
					
						
							|  |  |  | development early).
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |     $ git branch x.y
 | 
					
						
							|  |  |  |     $ git push origin x.y
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | The master branch configure.ac version should always be (at least)
 | 
					
						
							|  |  |  | x.y.90, with x.y being the most recent stable branch.  Stable branch
 | 
					
						
							|  |  |  | configure version is just whatever was most recently released from
 | 
					
						
							|  |  |  | that branch.
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | For stable branches, we commit fixes to master first, then cherry-pick
 | 
					
						
							|  |  |  | them back to the stable branch.
 |