diff options
Diffstat (limited to 'Build/source/libs/cairo/cairo-1.12.8/RELEASING')
| -rw-r--r-- | Build/source/libs/cairo/cairo-1.12.8/RELEASING | 140 |
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 |