| blob | 641ac1fc4a58700491f368de1a3b19fa6aaf8275 |
1 Here are the steps to follow to create a new cairo release:
3 1) Ensure that there are no local, uncommitted/unpushed
4 modifications. You're probably in a good state if both "git diff
5 HEAD" and "git log master..origin/master" give no output. Also make
6 sure you have libglib2.0-doc installed (else you'll get excessive
7 gtk-doc cross reference warnings in the next step).
9 2) Verify that the code passes "make distcheck"
11 First, make sure you have 'nm' and 'readelf' commands in PATH.
12 this should be OK with any Linux distro.
14 Running "make distcheck" should result in no warnings or
15 errors and end with a message of the form:
17 =============================================
18 cairo-X.Y.Z archives ready for distribution:
19 cairo-X.Y.Z.tar.gz
20 =============================================
22 (But the tar file isn't actually ready yet, as we still have
23 some more steps to follow).
25 Note that it's allowed (and perhaps recommended) to run the
26 "make distcheck" step against an all-software X server such as
27 Xvfb to avoid getting tripped up by any X-server-driver-specific
28 bugs. See test/README for details
30 If you get errors about local PLT entries, you get the list of
31 cairo entries with the error. For each of these, a call to
32 slim_hidden_def and slim_hidden_proto is needed in the cairo
33 implementation in the style of other similar calls.
35 In the unfortunate case that you have to push a snapshot out
36 (note, I said snapshot, not release) without the entire test
37 suite passing, here's the magic env vars to set when doing
38 'make distcheck' and 'make release-publish' that will let you
39 get away with it. At any cost, never ever release without
40 (implied) distchecking. Every time we got around it, it turned
41 out to be a disaster. Anyway, here's the pass code:
43 DISPLAY= CAIRO_TEST_TARGET=" "
45 3) Fill out an entry in the NEWS file
47 Sift through the logs since the last release. This is most
48 easily done with a command such as:
50 git log --stat X.Y.Z..
52 where X.Y.Z is the previous release version.
54 Summarize major changes briefly in a style similar to other
55 entries in NEWS. Take special care to note any additions in
56 the API. These should be easy to find by noting modifications
57 to .h files in the log command above. And more specifically,
58 the following command will show each patch that has changed a
59 public header file since the given version:
61 find src/ -name '*.h' ! -name '*-private.h' ! -name 'cairoint.h' ! -name 'cairo-*features*.h' | \
62 xargs git diff X.Y.Z.. --
64 4) Increment cairo_version_{minor|micro} in cairo-version.h:
66 If there are backward-incompatible changes in the API, stop
67 now and don't release. Go back and fix the API instead. Cairo
68 is intended to remain backwards-compatible as far as API.
70 So cairo_version_major will not be incremented unless we come
71 up with a new versioning scheme to take advantage of it.
73 If there are API additions, then increment cairo_version_minor
74 and reset cairo_version_micro to 0. NOTE: The minor version is
75 only incremented for releases, not for snapshots.
77 Otherwise, (i.e. there are only bug fixes), increment
78 cairo_version_micro to the next larger (even) number.
80 5) Commit the changes to NEWS and cairo-version.h
82 It's especially important to mention the new version number in your
83 commit log.
85 6) Run "make release-publish" which will perform the following steps
86 for you:
88 * Generate ChangeLog files out of git repository
89 * Check that ChangeLog files were generated properly
90 * Check that the version number ends with an even micro component
91 * Check that no release exists with the current version
92 * Verify that make distcheck completes successfully
93 * Generate the final tar file
94 * Generate an sha1sum file
95 * Sign the sha1sum using your GPG setup (asks for your GPG password)
96 * scp the three files to appear on http://cairographics.org/releases
97 * Generate a versioned manual and upload it to appear as both:
98 http://cairographics.org/manual-X.Y.Z
99 http://cairographics.org/manual
100 * Place local copies of the three files in the releases directory
101 * Create a LATEST-package-version file (after deleting any old one)
102 * Tag the entire source tree with a tag of the form X.Y.Z, and sign
103 the tag with your GPG key (asks for your GPG password, and you
104 may need to set GIT_COMMITTER_NAME and GIT_COMMITTER_EMAIL to match
105 your public-key's setting or this fails.)
106 * Provide some text for the release announcement (see below).
107 If for some reason you lost this message, "make release-publish-message"
108 prints it for you.
110 7) Increment cairo_version_micro to the next larger (odd) number in
111 cairo-version.h, commit, and push.
113 8) Push the newly created tag out to the central tree with a command
114 something like:
116 git push origin master X.Y.Z
118 9) Edit the cairo bugzilla product and add the new version numbers. Note
119 that you need to add two versions. One for the release/snapshot (with
120 an even micro version), another with the post-release version (with an
121 odd micro version).
123 10) Send a message to cairo-announce@cairographics.org and CC
124 cairo@cairographics.org, gnome-announce-list@gnome.org and
125 ftp-release@lists.freedesktop.org (pr@lwn.net as well for major
126 releases) to announce the new release using the text provided from
127 "make release-publish", adding the excerpt from NEWS, your
128 signature, followed by the standard "What is cairo" and "Where to
129 get more information about cairo" blurbs from README, and finally
130 the shortlog of all changes since last release, generated by:
132 git shortlog X.Y.Z...
134 where X.Y.Z is the last released version.
136 11) Edit the cairo wiki to add the announcement to the NEWS page and
137 the front page. (just the parts before your signature).