| 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 |