b73c58e6d7
Note that for weston, configure.ac needs version numbers updated in several places. `make distcheck` for weston no longer triggers the test suite to run, so update the directions to run a `make check` pre-release. Switch to using the X.org release.sh script in place of some of the manual steps. Signed-off-by: Bryce Harrington <bryce@osg.samsung.com> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
60 lines
2.5 KiB
Plaintext
60 lines
2.5 KiB
Plaintext
To make a release of Weston and/or Wayland, follow these steps.
|
|
|
|
0. 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 typically need updated as well.
|
|
|
|
1. Verify the test suites and codebase checks pass. (All of the
|
|
tests pass should pass except for xwayland, which can be flaky.)
|
|
|
|
$ make check
|
|
|
|
2. 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.
|
|
|
|
3. Compose a release announcement. The script will generate a
|
|
weston.x.y.0.announce file with a list of changes and tags.
|
|
Prepend this 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.
|
|
|
|
4. Send the release announcement to wayland-devel@lists.freedesktop.org
|
|
|
|
5. Get your freshly posted release email URL from
|
|
http://lists.freedesktop.org/archives/wayland-devel/
|
|
|
|
6. Update releases.html in wayland-web with links to tarballs and
|
|
the release email URL
|
|
|
|
7. Update topic in #wayland to point to the release announcement URL
|
|
|
|
For x.y.0 releases, also create the 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.
|