fdo-mirrors/weston
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/wayland/weston.git synced 2025-12-20 07:00:09 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions

releasing: update for the new release process

Browse source 
A few things have changed:

- Meson is used instead of autotools
- Wayland and Weston releases are not synchronized anymore
- Artifact deployment happens via wayland.freedesktop.org's Git repo

While at it, also convert the file to Markdown. Instructions to locally install
Xwayland/libinput have been dropped.

Signed-off-by: Simon Ser <contact@emersion.fr>
This commit is contained in:
Simon Ser 2019-07-19 20:21:48 +03:00 • committed by Pekka Paalanen
parent 3802241c46
commit d9cec1261c
2 changed files with 72 additions and 113 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

72
releasing.md Normal file
View file

@ -0,0 +1,72 @@
# Releasing
To make a release of Weston, follow these steps.
0. Verify the test suites and codebase checks pass. All of the tests should
either pass or skip.
ninja -C build/ test
1. Verify that the wayland and wayland-protocols version dependencies are
correct, and that wayland-protocols has had a release with any needed
protocol updates.
2. Update the first stanza of `meson.build` to the intended version.
If the ABI has been broken, make sure `libweston_major` has been bumped since
the last release.
Then commit your changes:
RELEASE_NUMBER="x.y.z"
RELEASE_NAME="[alpha|beta|RC1|RC2|official|point]"
git status
git commit meson.build -m "build: bump to version $RELEASE_NUMBER for the $RELEASE_NAME release"
git push
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:
https://gitlab.freedesktop.org/xorg/util/modular/blob/master/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 test suite 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 .
5. Compose the release announcements. The script will generate *.x.y.z.announce
files with a list of changes and tags. 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 announcement and send it to
<wayland-devel@lists.freedesktop.org>.
7. Update `releases.html` in wayland.freedesktop.org with links to tarballs and
the release email URL. Copy tarballs produced by `release.sh` to `releases/`.
Once satisfied:
git commit -am "releases: add ${RELEASE_NUMBER} release"
git push
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 `meson.build` version should always be (at least) x.y.90,
with x.y being the most recent stable branch. The stable branch's `meson.build`
version is just whatever was most recently released from that branch.
For stable branches, we commit fixes to master first, then `git cherry-pick -x`
them back to the stable branch.

113
releasing.txt
View file

@ -1,113 +0,0 @@
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 should either pass or skip.
$ make check
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.
2. Update the first stanza of configure.ac to the intended versions
for Weston and libweston.
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).
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.
Weston releases are made with the Weston version number, not with the
libweston version number.
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
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:
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/
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.