summaryrefslogtreecommitdiff
path: root/Build/source/libs/cairo/cairo-1.12.8/RELEASING
diff options
context:
space:
mode:
Diffstat (limited to 'Build/source/libs/cairo/cairo-1.12.8/RELEASING')
-rw-r--r--Build/source/libs/cairo/cairo-1.12.8/RELEASING140
1 files changed, 140 insertions, 0 deletions
diff --git a/Build/source/libs/cairo/cairo-1.12.8/RELEASING b/Build/source/libs/cairo/cairo-1.12.8/RELEASING
new file mode 100644
index 00000000000..a1edceba9cd
--- /dev/null
+++ b/Build/source/libs/cairo/cairo-1.12.8/RELEASING
@@ -0,0 +1,140 @@
+Here are the steps to follow to create a new cairo release:
+
+1) Ensure that there are no local, uncommitted/unpushed
+ modifications. You're probably in a good state if both "git diff
+ HEAD" and "git log master..origin/master" give no output.
+
+2) Verify that the code passes "make distcheck"
+
+ First, make sure you have 'nm' and 'readelf' commands in PATH.
+ this should be OK with any Linux distro.
+
+ Running "make distcheck" should result in no warnings or
+ errors and end with a message of the form:
+
+ =============================================
+ cairo-X.Y.Z archives ready for distribution:
+ cairo-X.Y.Z.tar.gz
+ =============================================
+
+ (But the tar file isn't actually ready yet, as we still have
+ some more steps to follow).
+
+ Note that it's allowed (and perhaps recommended) to run the
+ "make distcheck" step against an all-software X server such as
+ Xvfb to avoid getting tripped up by any X-server-driver-specific
+ bugs. See test/README for details
+
+ If you get errors about local PLT entries, you get the list of
+ cairo entries with the error. For each of these, a call to
+ slim_hidden_def and slim_hidden_proto is needed in the cairo
+ implementation in the style of other similar calls.
+
+ In the unfortunate case that you have to push a snapshot out
+ (note, I said snapshot, not release) without the entire test
+ suite passing, here's the magic env vars to set when doing
+ 'make distcheck' and 'make release-publish' that will let you
+ get away with it. At any cost, never ever release without
+ (implied) distchecking. Every time we got around it, it turned
+ out to be a disaster. Anyway, here's the pass code:
+
+ DISPLAY= CAIRO_TEST_TARGET=" "
+
+3) Fill out an entry in the NEWS file
+
+ Sift through the logs since the last release. This is most
+ easily done with a command 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' ! -name '*-private.h' ! -name 'cairoint.h' ! -name 'cairo-*features*.h' | \
+ xargs git diff X.Y.Z.. --
+
+4) Increment cairo_version_{minor|micro} in cairo-version.h:
+
+ 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, (i.e. there are only bug fixes), increment
+ cairo_version_micro to the next larger (even) number.
+
+5) Commit the changes to NEWS and cairo-version.h
+
+ 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:
+
+ * Generate ChangeLog files out of git repository
+ * Check that ChangeLog files were generated properly
+ * 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
+ * Generate a versioned manual and upload it to appear as both:
+ http://cairographics.org/manual-X.Y.Z
+ http://cairographics.org/manual
+ * 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) Increment cairo_version_micro to the next larger (odd) number in
+ cairo-version.h, commit, and push.
+
+8) Push the newly created tag out to the central tree with a command
+ something like:
+
+ git push cairo X.Y.Z
+
+9) Edit the cairo bugzilla product and add the new version numbers. Note
+ that you need to add two versions. One for the release/snapshot (with
+ an even micro version), another with the post-release version (with an
+ odd micro version).
+
+10) Send a message to cairo-announce@cairographics.org and CC
+ gnome-announce-list@gnome.org and ftp-release@lists.freedesktop.org
+ (pr@lwn.net as well for major releases) to announce the new release
+ using the text provided from "make release-publish", adding the excerpt
+ from NEWS, your signature, followed by the standard "What is cairo" and
+ "Where to get more information about cairo" blurbs from README, and
+ finally the shortlog of all changes since last release, generated by:
+
+ git shortlog X.Y.Z...
+
+ where X.Y.Z is the last released version.
+
+11) Edit the cairo wiki to add the announcement to the NEWS page and
+ the front page. (just the parts before your signature).
+
+12) For minor releases (no X.Y change), notify desktop-devel-list@gnome.org
+ or update the ExternalDependencies page for the current cycle if you
+ know where it is. Currently it's:
+
+ http://live.gnome.org/TwoPointNineteen/ExternalDependencies