mirror of
https://gitlab.freedesktop.org/cairo/cairo.git
synced 2025-12-25 21:10:10 +01:00
83 lines
3.1 KiB
Text
83 lines
3.1 KiB
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".
|
|
|