mirror of
https://gitlab.freedesktop.org/cairo/cairo.git
synced 2025-12-20 18:40:08 +01:00
8236282c5d
The man page for GNU find says:
-not expr
Same as ! expr, but not POSIX compliant.
And actually, on e.g. NetBSD, "-not" is not supported.
This resolved the following bug:
https://bugs.freedesktop.org/show_bug.cgi?id=10226
123 lines
5 KiB
Text
123 lines
5 KiB
Text
Here are the steps to follow to create a new cairo release:
|
|
|
|
1) Ensure that there are no local, uncommitted modifications.
|
|
It's probably good enough if "git diff HEAD" doesn't output
|
|
anything and your "master" and "origin" branchs are at the current
|
|
revision.
|
|
|
|
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-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).
|
|
|
|
If you get errors about local PLT entries, you get the list of
|
|
cairo and pixman entries with the error. For each of these, a
|
|
call to slim_hidden_def and slim_hidden_proto is needed in the
|
|
cairo or pixman implementation in the style of other similar calls.
|
|
|
|
3) Fill out an entry in the NEWS file
|
|
|
|
Sift through the logs since the last release. This is most
|
|
easily done with a comand 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 '*-test.h' ! -name 'cairoint.h' | \
|
|
xargs git log -p 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. NOTE: The minor version is
|
|
only incremented for releases, not for snapshots.
|
|
|
|
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 described in the
|
|
comments in configure.in.
|
|
|
|
5) Commit the changes to NEWS and configure.in
|
|
|
|
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
|
|
* 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
|
|
configure, 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 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 tacking on the detailed changelog-ish thing that gets
|
|
mailed out when you push the tag (but not the diffstat thing).
|
|
|
|
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/TwoPointSeventeen/ExternalDependencies
|