1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
|
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 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.
4. Send the release announcements 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.
|
