head 1.20; access; symbols RELEASE_1_0_2:1.20 BRANCH_1_0:1.20.0.2 RELEASE_1_0_0:1.20 BRANCH_SCALED_GLYPH:1.18.0.2 RELEASE_0_9_2:1.18 RELEASE_0_9_0:1.13 SNAPSHOT_0_6_0:1.11 SNAPSHOT_0_5_2:1.11 SNAPSHOT_0_5_1:1.11 SNAPSHOT_0_5_0:1.11 SNAPSHOT_0_4_0:1.9 SNAPSHOT_0_3_0:1.8 SNAPSHOT_0_2_0:1.5 LGPL_CHANGE_AFTER:1.3 LGPL_CHANGE_BEFORE:1.3 SNAPSHOT_0_1_23:1.3 SNAPSHOT_0_1_22:1.2 SNAPSHOT_0_1_21:1.2 SNAPSHOT_0_1_20:1.1; locks; strict; comment @# @; 1.20 date 2005.08.24.15.07.24; author cworth; state Exp; branches; next 1.19; commitid 3aae430c8d294567; 1.19 date 2005.08.24.12.28.28; author cworth; state Exp; branches; next 1.18; commitid 2ba7430c67e94567; 1.18 date 2005.08.13.12.00.20; author cworth; state Exp; branches; next 1.17; commitid 601642fde0d14567; 1.17 date 2005.08.13.07.20.45; author behdad; state Exp; branches; next 1.16; commitid 68e742fd9f434567; 1.16 date 2005.08.13.06.50.17; author cworth; state Exp; branches; next 1.15; commitid 5d5542fd98274567; 1.15 date 2005.08.13.04.35.31; author behdad; state Exp; branches; next 1.14; commitid 333642fd78854567; 1.14 date 2005.08.10.18.30.45; author cworth; state Exp; branches; next 1.13; commitid 793642fa47d34567; 1.13 date 2005.08.08.22.50.55; author cworth; state Exp; branches; next 1.12; commitid 655642f7e1cd4567; 1.12 date 2005.07.28.22.38.50; author cworth; state Exp; branches; next 1.11; commitid 4c742e95e784567; 1.11 date 2005.05.17.16.13.02; author cworth; state Exp; branches; next 1.10; commitid 33ba428a180c4567; 1.10 date 2005.05.17.16.08.23; author cworth; state Exp; branches; next 1.9; commitid 315e428a16f54567; 1.9 date 2005.01.23.20.49.56; author cworth; state Exp; branches; next 1.8; 1.8 date 2005.01.21.19.20.55; author cworth; state Exp; branches; next 1.7; 1.7 date 2004.11.04.22.23.50; author cworth; state Exp; branches; next 1.6; 1.6 date 2004.10.28.15.36.42; author cworth; state Exp; branches; next 1.5; 1.5 date 2004.10.27.20.13.39; author cworth; state Exp; branches; next 1.4; 1.4 date 2004.10.27.18.59.56; author cworth; state Exp; branches; next 1.3; 1.3 date 2004.05.11.15.19.47; author cworth; state Exp; branches; next 1.2; 1.2 date 2004.04.07.18.03.40; author cworth; state Exp; branches; next 1.1; 1.1 date 2004.04.07.03.13.11; author cworth; state Exp; branches; next ; desc @@ 1.20 log @2005-08-24 Carl Worth * RELEASING: Fix typo. @ text @Here are the steps to follow to create a new cairo release: 1) Ensure that there are no local, uncommitted modifications. The best thing to do here may be to begin with a fresh checkout from CVS: cvs -d cairographics.org:/cvs/cairo co cairo But it's probably good enough if "cvs -q update -Ad" generates no output. 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 information in ChangeLog since the last release. 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 looking for cairo*.h in the ChangeLog. Additionally, the output of the following command should be examined using the previous release tag: find src/ -name '*.h' -not -name '*-private.h' -not -name 'cairoint.h' | \ xargs cvs diff -r RELEASE_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. 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 describe in the comments in configure.in. 5) Commit the changes to NEWS and configure.in Don't forget to fill out the ChangeLog just like with any other commit. It's especially important to mention the new version number in the ChangeLog. 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 RELEASE_X_Y_Z * Provide some text for the release announcement (see below). 7) Increment cairo_version_micro to the next larger (odd) number in configure, and commit. 8) 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". @ 1.19 log @ 2005-08-24 Carl Worth * Makefile.am: * RELEASING: Change upload directory from snapshots to releases now thatwe're doing stable releases of cairo. @ text @d18 1 a18 1 caioo-X.Y.Z-head.tar.gz @ 1.18 log @ 2005-08-13 Carl Worth * NEWS: Added notes for release 0.9.2. * configure.in: Increment CAIRO_VERSION to 0.9.2 and libtool versioning to 3:1:1. * RELEASING: Remove some more 'snapshot' language. Make it more clear that the libtool versioning numbers need to be updated. @ text @d71 1 a71 1 * scp the three files to appear on http://cairographics.org/snapshots @ 1.17 log @2005-08-13 Behdad Esfahbod * RELEASING: * Makefile.am: Generate sh1sum instead of md5sum. Use gpg to sign it. You need gpg set up. @ text @d1 1 a1 6 So far, cairo hasn't reached an initial release. But we can still form good habits now by practicing the release process with the current snapshots. A new snapshot is needed whenever significant new features or bug fixes are committed. Here are the steps to follow: d37 2 a38 1 4) Increment cairo_version_{minor|micro} in configure.in: @ 1.16 log @ 2005-08-12 Carl Worth * RELEASING: * Makefile.am: Move tag from an instruction in RELEASING to an automated step at the end of release-publish. @ text @d69 1 d73 4 a76 2 * Generate an md5sum file * scp both files to appear on http://cairographics.org/snapshots d78 1 a78 1 * Place local copies of both files in the releases directory a79 1 * Tag the entire source tree with a tag of the form RELEASE_X_Y_Z @ 1.15 log @2005-08-13 Behdad Esfahbod * Makefile.am (release-publish): Check that the micro component of the version number is even. * RELEASING: Fixed the pattern to find all public header files. @ text @d77 1 d79 1 a79 5 7) Tag the entire source tree with a tag of the form RELEASE_X_Y_Z: cvs tag RELEASE_X_Y_Z 8) Increment cairo_version_micro to the next larger (odd) number in d82 1 a82 1 9) Send a message to cairo-announce@@cairographics.org and CC @ 1.14 log @ 2005-08-10 Carl Worth * Makefile.am: * RELEASING: Change release instructions to indicate new odd-micro version for in-progress development, and even-micro for released versions. Do a bit of snapshot->release renaming. @ text @d39 2 a40 4 cvs diff -r RELEASE_X_Y_Z src/*.h [Hmm, it would be nice to have a pattern for that command that would exclude private header files.] @ 1.13 log @ 2005-08-08 Carl Worth * RELEASING: Fix gnome-announce-list address. @ text @d32 1 a32 1 snapshot. Summarize major changes briefly in a style similar d34 1 a34 1 incompatible changes in the API. These should be easy to find d37 1 a37 1 previous snapshot tag: d39 1 a39 1 cvs diff -r SNAPSHOT_X_Y_Z src/*.h d44 1 a44 1 4) Increment CAIRO_VERSION in configure.in d46 3 a48 2 First, remove the "-head" suffix, then increment the version as follows: d50 2 a51 3 If there are backward-incompatible changes in the API, (function removals, or semantic changes), increment the minor number and reset the sub-minor number to 0. d53 2 a54 2 Otherwise, (that is, if there are only bug fixes and perhaps API additions), then increment only the sub-minor number. d56 5 a60 3 Prior to the initial "1.0" release of cairo, leave the major number at 0. Also, do not modify the "libtool shared library version" variables, (LT_CURRENT, LT_VERSION, LT_AGE). d80 1 a80 1 7) Tag the entire source tree with a tag of the form SNAPSHOT_X_Y_Z: d82 1 a82 1 cvs tag SNAPSHOT_X_Y_Z d84 2 a85 1 8) Add a "-head" to CAIRO_VERSION in configure, and commit. d89 1 a89 1 new snapshot using the text provided from "make release-publish". @ 1.12 log @ * RELEASING: CC gnome-announce-list@@gnome.org on cairo release announcements. @ text @d85 1 a85 1 gnome-announce-list to announce the @ 1.11 log @ * util/cairo-api-update: Remove #ifdef munging since we once again support either #if or #ifdef. @ text @d84 2 a85 1 9) Send a message to cairo-announce@@cairographics.org to announce the @ 1.10 log @ * RELEASING: Update instructions to match output of 'make distcheck' * src/Makefile.am: * test/Makefile.am: Add private headers and flesh out CLEANFILES so that 'make distcheck' actually passes. @ text @d35 1 a35 1 by looking for cairo.h in the ChangeLog. Additionally, the d39 4 a42 1 cvs diff -r SNAPSHOT_X_Y_Z src/cairo.h @ 1.9 log @ * RELEASING: Add instructions for handling the new -head suffix of CAIRO_VERSION at release-time. * configure.in: Append -head to CAIRO_VERSION to indicate state between snapshots. @ text @d21 4 a24 3 ================================================ cairo-X.Y.Z.tar.gz is ready for distribution ================================================ @ 1.8 log @ * Makefile.am (RELEASE_UPLOAD_DIR): Update since directory changed after server compromise. @ text @d42 13 a54 9 Right now, in its pre-release form, we are incrementing CAIRO_VERSION for each snapshot but we are not changing the libtool shared library version information. Increment the subminor version for bug fixes and backwards-compatible additions to the API. Increment the minor number (and reset the subminor) for backward-incompatible changes to the API (including removals). Leave the major number at 0 until we are ready for the first 1.0 release, (at which point these rules will change). d78 2 @ 1.7 log @ * test/text_cache_crash.c: Add new test demonstrating assertion failure in cairo_cache_lookup. * test/text_rotate.c: Add new test showing problems with rotated text. @ text @d35 2 a36 2 output following command should be examined using the previous snapshot tag: d65 1 a65 1 * scp both files to cairographics.org:/home/www/cairo/snapshots @ 1.6 log @ * Makefile.am (release-verify-newer): Abort release-publish if there's already a published tar file with the current version. (release-publish): Add code to update the LATEST-package-version file. @ text @d61 1 a61 1 * Check that no release exist with the current version @ 1.5 log @ * configure.in: Increment CAIRO_VERSION to 0.2.0. * NEWS: Add notes for snapshot 0.2.0. @ text @d61 1 d63 1 a63 1 * Generate the final tar file with the correct version number d66 1 d68 1 a68 1 * Provide some text for the release announcement d74 2 a75 2 8) Send a message to cairo-announce@@cairographics.org to announce the new snapshot using the text provided by the previous step. @ 1.4 log @ * RELEASING: Update release instructions for new release-publish target. * Makefile.am: Add release-check and release-publish targets copied from libpixman. @ text @d34 5 a38 1 by looking for cairo.h in the ChangeLog. @ 1.3 log @ * configure.in: Increment CAIRO_VERSION to 0.1.23. * NEWS: Added notes for snapshot 0.1.23. * RELEASING: Add reminder to mention incompatible API changes in NEWS. Re-order steps to avoid clobbering pre-existing tar files. @ text @d5 2 a6 2 10 easy steps to creating a new cairo snapshot ============================================== d8 2 a9 2 1) Commit code with a significant new feature or backwards incompatibility. d11 1 a11 4 Either of these events triggers the need for a new snapshot. Users of cairo snapshots need to be able to specify snapshot version numbers in order to get access to a specific set of features. d13 2 a14 1 2) Increment CAIRO_VERSION in configure.in d16 1 a16 7 Right now, in its pre-release form, we are incrementing CAIRO_VERSION for each snapshot but we are not changing the libtool shared library version information. Until now, we've only incremented the sub-minor version. We'll invent rules for incrementing major and minor numbers when the time is right. 3) Verify that the code passes "make distcheck" d21 1 a21 1 ============================================= d23 1 a23 1 ============================================= d28 1 a28 1 4) Fill out an entry in the NEWS file d36 12 d54 2 a55 2 6) Run "make distcheck" to generate the final tar file including the changes to NEWS and ChangeLog. d57 6 a62 2 7) Copy the resulting tar file to the cairo snapshots distribution directory: d64 1 a64 3 scp cairo-X.Y.Z-tar.gz cairographics.org:/home/www/cairo/snapshots 8) Tag the entire source tree with a tag of the form SNAPSHOT_X_Y_Z: d68 2 a69 9 9) Send a message to cairo-announce@@cairographics.org to announce the new snapshot. The message should provide the URL for the snapshot: http://cairographics.org/snapshots/cairo-X.Y.Z.tar.gz and should also include the relevant section from the NEWS file. a70 2 10) Sit back and relax in confidence, or alternately, brace yourself for a flood of new bug reports. @ 1.2 log @Add note that announcement needs to include the URL @ text @d16 9 a24 1 2) Verify that the code passes "make distcheck" d36 1 a36 1 3) Fill out an entry in the NEWS file d40 3 a42 9 to other entries in NEWS. 4) Increment CAIRO_VERSION in configure.in Right now, in its pre-release form, we are incrementing CAIRO_VERSION for each snapshot but we are not changing the libtool shared library version information. Until now, we've only incremented the sub-minor version. We'll invent rules for incrementing major and minor numbers when the time is right. d50 2 a51 2 6) Run "make distcheck" to generate the final tar file with the correct version number. @ 1.1 log @ * NEWS: Added notes for snapshot 0.1.20. * RELEASING: Added new RELEASING file. @ text @d63 1 a63 2 This is as simple as cutting and pasting the new section of the NEWS file into the body of the message. d65 7 a71 2 10) Sit back and relax in confidence, (or brace yourself for a flood of new bug reports). It's up to you! @