-To make a release follow these steps.
+To make a release of Weston and/or Wayland, follow these steps.
- 1. Update configure.ac to intended version, commit.
+ 0. Verify the test suites and codebase checks pass. All of the
+ tests should either pass or skip.
- 2. make distcheck (for weston I do make distcheck TESTS= to avoid
- running the tests... most of the tests pass, but the xwayland one
- is flaky)
+ $ make check
- 3. git tag -am 1.5.0 1.5.0
+ 1. For Weston, verify that the wayland and wayland-protocols version
+ dependencies are correct, and that wayland-protocols has had a
+ release with any needed protocol updates.
- 4. scp tarballs to /srv/wayland.freedesktop.org/www/releases on
- annarchy.freedesktop.org
+ 2. Update the first stanza of configure.ac to the intended versions
+ for Weston and libweston.
- 5. Put SHA1 for tarballs and tagged commits in release announcement
+ For Weston's x.y.0 releases, if libweston_major_version is greater than
+ weston_major_version, bump the Weston version numbers (major, minor,
+ micro) to match the libweston version numbers (major, minor, patch).
- 6. Push configure.ac commits and tags.
+ Additionally for all Weston releases, if libweston's
+ major.minor.patch version is less than Weston's major.minor.micro
+ version, bump libweston version numbers to match the Weston
+ version numbers.
- 7. Send out release announcement.
+ Weston releases are made with the Weston version number, not with the
+ libweston version number.
- 8. Get the release email URL from
- http://lists.freedesktop.org/archives/wayland-devel/
+ Then commit your changes:
- 9. Update releases.html in wayland-web with links to tarballs and
- release email.
+ $ 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
- 10. Update topic in #wayland to point to release announcement
+ 3. 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:
-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).
+ XWAYLAND=$(which Xwayland) # Or specify your own path
+ export DISTCHECK_CONFIGURE_FLAGS="--with-xserver-path=$XWAYLAND"
-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.
+ 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/
+
+ 4. 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 official and point releases, also publish the publican
+ documentation to wayland.freedesktop.org:
+
+ $ ./publish-doc
+
+ 5. Compose the release announcements. The script will generate
+ *.x.y.z.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.
+
+ 6. pgp sign the release announcements and send them to
+ wayland-devel@lists.freedesktop.org
+
+ 7. Update releases.html in wayland-web with links to tarballs and
+ the release email URL.
+
+ The wl_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/wl_register_release x.y.z") and
+ customized.
+
+ Once satisfied:
+
+ $ git commit ./releases.html -m "releases: 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 create 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 [sha]
+ $ git push origin x.y
+
+The master branch's configure.ac version should always be (at least)
+x.y.90, with x.y being the most recent stable branch. The stable
+branch's configure.ac 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.
projects / platform / upstream / weston.git / blobdiff