2015-01-10 05:09:21 +03:00
|
|
|
To make a release of Weston and/or Wayland, follow these steps.
|
2014-05-23 21:13:59 +04:00
|
|
|
|
2015-02-07 05:01:33 +03:00
|
|
|
0. Verify the test suites and codebase checks pass. All of the
|
|
|
|
tests pass should either pass or skip.
|
|
|
|
|
|
|
|
$ make check
|
|
|
|
|
2015-11-18 05:45:28 +03:00
|
|
|
1. Verify that the wayland-protocols version dependency is correct,
|
|
|
|
and that wayland-protocols has had a release with any needed
|
|
|
|
protocol updates.
|
|
|
|
|
|
|
|
2. Update the first three lines of configure.ac to the intended
|
2015-01-10 05:09:21 +03:00
|
|
|
version, commit. Also note that Weston includes versioned
|
|
|
|
dependencies on 'wayland-server' and 'wayland-client' in
|
2015-08-17 00:16:26 +03:00
|
|
|
configure.ac which occasionally need updated as well. Then commit
|
2015-02-07 05:01:33 +03:00
|
|
|
your changes:
|
2014-05-23 21:13:59 +04:00
|
|
|
|
2015-05-28 09:55:08 +03:00
|
|
|
$ export RELEASE_NUMBER="x.y.z"
|
2015-08-17 00:00:05 +03:00
|
|
|
$ export RELEASE_NAME="[alpha|beta|RC1|RC2|official|point]"
|
2015-02-07 05:01:33 +03:00
|
|
|
$ git status
|
2015-05-27 05:20:37 +03:00
|
|
|
$ git commit configure.ac -m "configure.ac: bump to version $RELEASE_NUMBER for the $RELEASE_NAME release"
|
2015-02-07 05:01:33 +03:00
|
|
|
$ git push
|
2014-05-23 21:13:59 +04:00
|
|
|
|
2015-11-18 05:45:28 +03:00
|
|
|
3. For Weston releases, install Xwayland, either from your distro or
|
2015-02-14 07:46:41 +03:00
|
|
|
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:
|
2015-02-13 03:49:15 +03:00
|
|
|
|
2015-09-18 02:33:48 +03:00
|
|
|
XWAYLAND=$(which Xwayland) # Or specify your own path
|
|
|
|
export DISTCHECK_CONFIGURE_FLAGS="--with-xserver-path=$XWAYLAND"
|
2015-02-13 03:49:15 +03:00
|
|
|
|
2015-05-16 04:51:19 +03:00
|
|
|
If you're using a locally installed libinput or other dependency
|
|
|
|
libraries, you'll likely need to set a few other environment
|
|
|
|
variables:
|
2015-05-16 04:50:04 +03:00
|
|
|
|
2015-05-16 04:51:19 +03:00
|
|
|
export WLD="<path-to-your-local-installation>"
|
|
|
|
export LD_LIBRARY_PATH=$WLD/lib
|
|
|
|
export PKG_CONFIG_PATH=$WLD/lib/pkgconfig:$WLD/share/pkgconfig/
|
2015-05-16 04:50:04 +03:00
|
|
|
|
2015-11-18 05:45:28 +03:00
|
|
|
4. Run the release.sh script to generate the tarballs, sign and
|
2015-01-10 05:09:21 +03:00
|
|
|
upload them, and generate a release announcement template.
|
|
|
|
This script can be obtained from X.org's modular package:
|
2014-05-23 21:13:59 +04:00
|
|
|
|
2015-01-10 05:09:21 +03:00
|
|
|
http://cgit.freedesktop.org/xorg/util/modular/tree/release.sh
|
2014-05-23 21:13:59 +04:00
|
|
|
|
2015-01-10 05:09:21 +03:00
|
|
|
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.
|
2014-05-23 21:13:59 +04:00
|
|
|
|
2015-05-28 09:55:08 +03:00
|
|
|
$ release.sh .
|
2015-05-27 05:20:37 +03:00
|
|
|
|
2015-05-28 09:55:08 +03:00
|
|
|
For wayland, also publish the publican documentation to
|
|
|
|
wayland.freedesktop.org:
|
2015-05-28 01:33:27 +03:00
|
|
|
|
2015-05-28 09:55:08 +03:00
|
|
|
$ ./publish-doc
|
2015-05-28 01:33:27 +03:00
|
|
|
|
|
|
|
|
2015-11-18 05:45:28 +03:00
|
|
|
5. Compose the release announcements. The script will generate
|
2016-01-20 22:50:12 +03:00
|
|
|
*.x.y.z.announce files with a list of changes and tags, one for
|
2015-01-27 05:23:37 +03:00
|
|
|
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.
|
|
|
|
|
2015-11-18 05:45:28 +03:00
|
|
|
6. pgp sign the the release announcements and send them to
|
2015-01-27 05:23:37 +03:00
|
|
|
wayland-devel@lists.freedesktop.org
|
2015-01-10 05:09:21 +03:00
|
|
|
|
2016-01-20 22:50:12 +03:00
|
|
|
7. Update releases.html in wayland-web with links to tarballs and
|
2015-01-31 06:10:12 +03:00
|
|
|
the release email URL.
|
|
|
|
|
2016-05-05 00:58:24 +03:00
|
|
|
The wl_register_release script in wayland-web will generate an HTML
|
2015-05-28 09:55:08 +03:00
|
|
|
snippet that can be pasted into releases.html (or e.g. in emacs
|
2016-02-12 02:23:33 +03:00
|
|
|
insert it via "C-u M-! scripts/register_release x.y.z") and
|
2015-05-28 09:55:08 +03:00
|
|
|
customized.
|
2015-05-27 23:03:42 +03:00
|
|
|
|
2015-05-28 09:55:08 +03:00
|
|
|
Once satisfied:
|
2015-05-27 23:03:42 +03:00
|
|
|
|
2016-01-20 22:50:12 +03:00
|
|
|
$ git commit ./releases.html -m "releases: Add ${RELEASE_NUMBER} release"
|
2015-01-31 06:10:12 +03:00
|
|
|
$ git push
|
2015-05-28 01:33:27 +03:00
|
|
|
$ ./deploy
|
2014-05-23 21:13:59 +04:00
|
|
|
|
2016-01-20 22:50:12 +03:00
|
|
|
8. Update topic in #wayland to point to the release announcement URL
|
2014-05-23 21:13:59 +04:00
|
|
|
|
2015-05-27 23:06:59 +03:00
|
|
|
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).
|
2014-05-23 21:13:59 +04:00
|
|
|
|
2015-01-10 05:09:21 +03:00
|
|
|
$ git branch x.y
|
|
|
|
$ git push origin x.y
|
|
|
|
|
2014-05-23 21:13:59 +04:00
|
|
|
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.
|