releasing.txt 4.54 KB
Newer Older
1
To make a release of Weston and/or Wayland, follow these steps.
2

3
  0.  Verify the test suites and codebase checks pass.  All of the
4
      tests should either pass or skip.
5 6 7

      $ make check

8 9 10
  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.
11

12
  2.  Update the first stanza of configure.ac to the intended versions
Bryce Harrington's avatar
Bryce Harrington committed
13
      for Weston and libweston.
14 15 16 17 18

      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).

Bryce Harrington's avatar
Bryce Harrington committed
19 20 21 22
      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.
23 24 25 26 27

      Weston releases are made with the Weston version number, not with the
      libweston version number.

      Then commit your changes:
28

29
      $ export RELEASE_NUMBER="x.y.z"
30
      $ export RELEASE_NAME="[alpha|beta|RC1|RC2|official|point]"
31
      $ git status
32
      $ git commit configure.ac -m "configure.ac: bump to version $RELEASE_NUMBER for the $RELEASE_NAME release"
33
      $ git push
34

35
  3.  For Weston releases, install Xwayland, either from your distro or
36 37 38
      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:
39

40 41
	  XWAYLAND=$(which Xwayland)  # Or specify your own path
      export DISTCHECK_CONFIGURE_FLAGS="--with-xserver-path=$XWAYLAND"
42

Bryce Harrington's avatar
Bryce Harrington committed
43 44 45
      If you're using a locally installed libinput or other dependency
      libraries, you'll likely need to set a few other environment
      variables:
46

Bryce Harrington's avatar
Bryce Harrington committed
47 48 49
      export WLD="<path-to-your-local-installation>"
      export LD_LIBRARY_PATH=$WLD/lib
      export PKG_CONFIG_PATH=$WLD/lib/pkgconfig:$WLD/share/pkgconfig/
50

51
  4.  Run the release.sh script to generate the tarballs, sign and
52 53
      upload them, and generate a release announcement template.
      This script can be obtained from X.org's modular package:
54

55
        http://cgit.freedesktop.org/xorg/util/modular/tree/release.sh
56

57 58 59 60 61
      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.
62

63
      $ release.sh .
64

65 66
      For Wayland official and point releases, also publish the publican
      documentation to wayland.freedesktop.org:
67

68
      $ ./publish-doc
69

70
  5.  Compose the release announcements.  The script will generate
71
      *.x.y.z.announce files with a list of changes and tags, one for
72 73 74 75
      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.

Abdur Rehman's avatar
Abdur Rehman committed
76
  6.  pgp sign the release announcements and send them to
77
      wayland-devel@lists.freedesktop.org
78

79
  7.  Update releases.html in wayland-web with links to tarballs and
80 81
      the release email URL.

82
      The wl_register_release script in wayland-web will generate an HTML
83
      snippet that can be pasted into releases.html (or e.g. in emacs
84
      insert it via "C-u M-! scripts/wl_register_release x.y.z") and
85
      customized.
86

87
      Once satisfied:
88

89
      $ git commit ./releases.html -m "releases: Add ${RELEASE_NUMBER} release"
90
      $ git push
91
      $ ./deploy
92

93
  8.  Update topic in #wayland to point to the release announcement URL
94

95 96
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,
97
and is where we create x.y.z releases from.  Creating the x.y branch
98 99 100 101 102
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).
103

104
    $ git branch x.y [sha]
105 106
    $ git push origin x.y

Bryce Harrington's avatar
Bryce Harrington committed
107 108 109 110
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.
111 112 113

For stable branches, we commit fixes to master first, then cherry-pick
them back to the stable branch.