Skip to content
Permalink
Newer
Older
100644 193 lines (139 sloc) 7.38 KB
August 13, 2005 05:00
1
Here are the steps to follow to create a new cairo release:
April 6, 2004 20:13
2
3
1) Ensure that there are no local, uncommitted/unpushed mods.
4
5
You're probably in a good state if both "git diff
6
HEAD" and "git log master..origin/master" give no output. Also make
7
sure you have libglib2.0-doc installed (else you'll get
8
excessive gtk-doc cross reference warnings in the next step).
9
10
2) Verify that the code passes "make distcheck"
April 6, 2004 20:13
11
12
First, make sure you have 'nm' and 'readelf' commands in PATH.
December 14, 2008 11:40
13
this should be OK with any Linux distro.
14
April 6, 2004 20:13
15
Running "make distcheck" should result in no warnings or
16
errors and end with a message of the form:
17
18
=============================================
19
cairo-X.Y.Z archives ready for distribution:
20
cairo-X.Y.Z.tar.gz
21
=============================================
April 6, 2004 20:13
22
23
(But the tar file isn't actually ready yet, as we still have
24
some more steps to follow).
25
26
Note that it's allowed (and perhaps recommended) to run the
27
"make distcheck" step against an all-software X server such as
28
Xvfb to avoid getting tripped up by any X-server-driver-specific
29
bugs. See test/README for details
30
31
If you get errors about local PLT entries, you get the list of
32
cairo entries with the error. For each of these, a call to
33
slim_hidden_def and slim_hidden_proto is needed in the cairo
34
implementation in the style of other similar calls.
35
36
In the unfortunate case that you have to push a snapshot out
37
(note, I said snapshot, not release) without the entire test
38
suite passing, here's the magic env vars to set when doing
39
'make distcheck' and 'make release-publish' that will let you
40
get away with it. At any cost, never ever release without
41
(implied) distchecking. Every time we got around it, it turned
42
out to be a disaster. Anyway, here's the pass code:
43
44
DISPLAY= CAIRO_TEST_TARGET=" "
45
46
3) Decide what the new version number for the release will be.
47
48
There are three types of releases: Minor, Micro, and
49
Snapshot. Micro releases should be only bugfixes and no API
50
additions. If there are API additions consider making a Minor
51
release. Snapshot releases can be done of the current
52
development tree between Minor releases, as desired.
53
54
Cairo uses even numbers for official releases, and odd numbers
55
for development snapshots. Thus, for a Minor release it would
56
be:
57
58
LAST_RELEASE="X.Y.Z" # e.g. 1.12.0
59
THIS_RELEASE="X.Y+2.0" # e.g. 1.14.0
60
61
While for a Micro release the version numbers should be:
62
63
LAST_RELEASE="X.Y.Z" # e.g. 1.14.0
64
THIS_RELEASE="X.Y.Z+2" # e.g. 1.14.2
65
66
Snapshots are similar but have odd minor versions. Also, the
67
first snapshot release in a new series will be .2 rather than
68
.0, e.g.:
69
70
LAST_RELEASE="X.Y.Z" # e.g. 1.14.0
71
THIS_RELEASE="X.Y+1.0" # e.g. 1.15.2
72
73
and subsequent snapshots in that series are just normal micro
74
releases:
75
76
LAST_RELEASE="X.Y.Z" # e.g. 1.15.2
77
THIS_RELEASE="X.Y.Z+2" # e.g. 1.15.4
78
79
80
81
4) Fill out an entry in the NEWS file
April 6, 2004 20:13
82
83
Sift through the logs since the last release. This is most
December 14, 2008 11:40
84
easily done with a command such as:
85
86
git log --stat ${LAST_RELEASE}..
87
88
Summarize major changes briefly in a style similar to other
89
entries in NEWS. Take special care to note any additions in
90
the API. These should be easy to find by noting modifications
91
to .h files in the log command above. And more specifically,
92
the following command will show each patch that has changed a
93
public header file since the given version:
October 27, 2004 13:13
94
October 27, 2015 13:53
95
find src/ -name '*.h' ! -name '*-private.h' \
96
! -name 'cairoint.h' ! -name 'cairo-*features*.h' | \
97
xargs git diff ${LAST_RELEASE}.. --
April 6, 2004 20:13
98
October 27, 2015 13:53
99
Include a link to the incremental ChangeLog for this release,
100
which we'll be uploading in a later step:
101
102
http://cairographics.org/releases/ChangeLog.cairo-${THIS_RELEASE}
103
104
4) Increment cairo_version_{minor|micro} in cairo-version.h:
105
106
If there are backward-incompatible changes in the API, stop
107
now and don't release. Go back and fix the API instead. Cairo
108
is intended to remain backwards-compatible as far as API.
109
110
So cairo_version_major will not be incremented unless we come
111
up with a new versioning scheme to take advantage of it.
112
113
If there are API additions, then increment cairo_version_minor
114
and reset cairo_version_micro to 0. NOTE: The minor version is
115
only incremented for releases, not for snapshots.
116
December 14, 2008 11:40
117
Otherwise, (i.e. there are only bug fixes), increment
118
cairo_version_micro to the next larger (even) number.
119
120
5) Commit the changes to NEWS and cairo-version.h
April 6, 2004 20:13
121
122
It's especially important to mention the new version number in your
123
commit log.
April 6, 2004 20:13
124
125
6) Run "make release-publish" which will perform the following steps
126
for you:
April 6, 2004 20:13
127
128
* Generate ChangeLog files out of git repository
129
* Check that ChangeLog files were generated properly
130
* Check that the version number ends with an even micro component
131
* Check that no release exists with the current version
132
* Verify that make distcheck completes successfully
133
* Generate the final tar file
134
* Generate an sha1sum file
135
* Sign the sha1sum using your GPG setup (asks for your GPG password)
136
* scp the three files to appear on http://cairographics.org/releases
137
* Generate a versioned manual and upload it to appear as both:
138
http://cairographics.org/manual-${THIS_RELEASE}
139
http://cairographics.org/manual
140
* Place local copies of the three files in the releases directory
141
* Create a LATEST-package-version file (after deleting any old one)
142
* Tag the entire source tree with a ${THIS_RELEASE} tag, and sign
143
the tag with your GPG key (asks for your GPG password, and you
144
may need to set GIT_COMMITTER_NAME and GIT_COMMITTER_EMAIL to match
145
your public-key's setting or this fails.)
146
* Provide some text for the release announcement (see below).
147
If for some reason you lost this message, "make release-publish-message"
148
prints it for you.
April 6, 2004 20:13
149
150
Upload the incremental ChangeLog generated by the above:
151
152
scp ChangeLog.cache-${LAST_RELEASE}.. \
153
cairographics.org:/srv/cairo.freedesktop.org/www/releases/ChangeLog.cairo-${THIS_RELEASE}
October 27, 2015 13:53
154
155
To undo a release-publish, before you've sent any emails or
156
pushed changes to master, delete the locally created tag (git
157
tag -d ${THIS_RELEASE}); then log into the webserver, repoint
158
the manual and LATEST-cairo-${THIS_RELEASE} symlinks to the
159
previous versions, remove manual-${THIS_RELEASE} and
160
release/cairo-${THIS_RELEASE}.
161
162
7) Update trunk (or the stable branch) version number.
163
164
For Micro releases (X.Y.Z), increment cairo_version_micro to the
165
next larger (odd) number in cairo-version.h, commit, and push.
166
167
For Minor releases (X.Y.0), increment cairo_version_minor to the
168
next larger (odd) number, and set cairo_version_micro to 1. Then
169
commit and push.
170
171
8) Push the new tag out to the central tree with a command like:
172
173
git push origin master ${THIS_RELEASE}
174
175
9) Edit the cairo bugzilla product and add the new version numbers.
176
177
Note that you need to add two versions. One for the
178
release/snapshot (with an even micro version), another with the
179
post-release version (with an odd micro version).
180
181
10) Send out an announcement message.
182
183
Send a message to cairo-announce@cairographics.org and CC
184
cairo@cairographics.org, gnome-announce-list@gnome.org and
185
ftp-release@lists.freedesktop.org (pr@lwn.net as well for major
186
releases) to announce the new release using the text provided from
187
"make release-publish", adding the excerpt from NEWS and
188
the shortlog of all changes since last release, generated by:
189
190
git shortlog ${LAST_RELEASE}...
August 11, 2008 13:09
191
192
11) Add the announcement to the NEWS page and the front page.
193