Here are the steps to follow to create a new cairo release:

1) Ensure that there are no local, uncommitted modifications.
   It's probably good enough if "git diff HEAD" doesn't output
   anything and your "master" and "origin" branchs are at the current
   revision.

2) Verify that the code passes "make distcheck"

	Running "make distcheck" should result in no warnings or
	errors and end with a message of the form:

	==================================================
	cairo-X.Y.Z-head archives ready for distribution:
	cairo-X.Y.Z-head.tar.gz
	==================================================

	(But the tar file isn't actually ready yet, as we still have
	some more steps to follow).

3) Fill out an entry in the NEWS file

	Sift through the logs since the last release. This is most
	easily done with a comand such as:

		git log --stat X.Y.Z..

	where X.Y.Z is the previous release version.

	Summarize major changes briefly in a style similar to other
	entries in NEWS. Take special care to note any additions in
	the API. These should be easy to find by noting modifications
	to .h files in the log command above. And more specifically,
	the following command will show each patch that has changed a
	public header file since the given version:

		find src/ -name '*.h' -not -name '*-private.h' -not -name '*-test.h' -not -name 'cairoint.h' | \
		xargs git log -p X.Y.Z.. --

4) Increment cairo_version_{minor|micro} and LT_{CURRENT|VERSION|AGE}
   in configure.in:

	If there are backward-incompatible changes in the API, stop
	now and don't release. Go back and fix the API instead. Cairo
	is intended to remain backwards-compatible as far as API.

	So cairo_version_major will not be incremented unless we come
	up with a new versioning scheme to take advantage of it.

	If there are API additions, then increment cairo_version_minor
	and reset cairo_version_micro to 0. NOTE: The minor version is
	only incremented for releases, not for snapshots.

	Otherwise, (ie. there are only bug fixes), increment
	cairo_version_micro to the next larger (even) number.

	Adjust LT_CURRENT, LT_VERSION, and LT_AGE as described in the
	comments in configure.in.

5) Commit the changes to NEWS and configure.in

	It's especially important to mention the new version number in your
	commit log.

6) Run "make release-publish" which will perform the following steps
   for you:

	* Check that the version number ends with an even micro component
	* Check that no release exists with the current version
	* Verify that make distcheck completes successfully
	* Generate the final tar file
	* Generate an sha1sum file
	* Sign the sha1sum using your GPG setup (asks for your GPG password)
	* scp the three files to appear on http://cairographics.org/releases
	* Place local copies of the three files in the releases directory
	* Create a LATEST-package-version file (after deleting any old one)
	* Tag the entire source tree with a tag of the form X.Y.Z, and sign
	  the tag with your GPG key (asks for your GPG password, and you
	  may need to set GIT_COMMITTER_NAME and GIT_COMMITTER_EMAIL to match
	  your public-key's setting or this fails.)
	* Provide some text for the release announcement (see below).
	  If for some reason you lost this message, "make release-publish-message"
	  prints it for you.

7) Push the newly created tag out to the central tree wih a command something like:

	git push cairo X.Y.Z

8) Increment cairo_version_micro to the next larger (odd) number in
   configure, commit, and push.

9) Edit the cairo bugzilla product and add the new version numbers

10) Send a message to cairo-announce@cairographics.org and CC
    gnome-announce-list@gnome.org to announce the new release using
    the text provided from "make release-publish", adding the standard
    "What is cairo" and "Where to get more information about cairo"
    blurbs from README, and also tacking on the detailed changelog-ish
    thing that gets mailed out when you push the tag.

11) Edit the cairo wiki to add the announcement to the NEWS page and
    the front page.