-
Notifications
You must be signed in to change notification settings - Fork 4
/
RELEASING
193 lines (139 loc) · 7.36 KB
/
RELEASING
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
Here are the steps to follow to create a new cairo release:
1) Ensure that there are no local, uncommitted/unpushed mods.
You're probably in a good state if both "git diff
HEAD" and "git log master..origin/master" give no output. Also make
sure you have libglib2.0-doc installed (else you'll get
excessive gtk-doc cross reference warnings in the next step).
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) Decide what the new version number for the release will be.
There are three types of releases: Minor, Micro, and
Snapshot. Micro releases should be only bugfixes and no API
additions. If there are API additions consider making a Minor
release. Snapshot releases can be done of the current
development tree between Minor releases, as desired.
Cairo uses even numbers for official releases, and odd numbers
for development snapshots. Thus, for a Minor release it would
be:
LAST_RELEASE="X.Y.Z" # e.g. 1.12.0
THIS_RELEASE="X.Y+2.0" # e.g. 1.14.0
While for a Micro release the version numbers should be:
LAST_RELEASE="X.Y.Z" # e.g. 1.14.0
THIS_RELEASE="X.Y.Z+2" # e.g. 1.14.2
Snapshots are similar but have odd minor versions. Also, the
first snapshot release in a new series will be .2 rather than
.0, e.g.:
LAST_RELEASE="X.Y.Z" # e.g. 1.14.0
THIS_RELEASE="X.Y+1.0" # e.g. 1.15.2
and subsequent snapshots in that series are just normal micro
releases:
LAST_RELEASE="X.Y.Z" # e.g. 1.15.2
THIS_RELEASE="X.Y.Z+2" # e.g. 1.15.4
4) 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 ${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 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 ${LAST_RELEASE}.. --
Include a link to the incremental ChangeLog for this release,
which we'll be uploading in a later step:
http:https://cairographics.org/releases/ChangeLog.cairo-${THIS_RELEASE}
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:https://cairographics.org/releases
* Generate a versioned manual and upload it to appear as both:
http:https://cairographics.org/manual-${THIS_RELEASE}
http:https://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 ${THIS_RELEASE} tag, 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.
Upload the incremental ChangeLog generated by the above:
scp ChangeLog.cache-${LAST_RELEASE}.. \
cairographics.org:/srv/cairo.freedesktop.org/www/releases/ChangeLog.cairo-${THIS_RELEASE}
To undo a release-publish, before you've sent any emails or
pushed changes to master, delete the locally created tag (git
tag -d ${THIS_RELEASE}); then log into the webserver, repoint
the manual and LATEST-cairo-${THIS_RELEASE} symlinks to the
previous versions, remove manual-${THIS_RELEASE} and
release/cairo-${THIS_RELEASE}.
7) Update trunk (or the stable branch) version number.
For Micro releases (X.Y.Z), increment cairo_version_micro to the
next larger (odd) number in cairo-version.h, commit, and push.
For Minor releases (X.Y.0), increment cairo_version_minor to the
next larger (odd) number, and set cairo_version_micro to 1. Then
commit and push.
8) Push the new tag out to the central tree with a command like:
git push origin master ${THIS_RELEASE}
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 out an announcement message.
Send a message to [email protected] and CC
[email protected] ([email protected] as well for major
releases) to announce the new release using the text provided from
"make release-publish", adding the excerpt from NEWS and
the shortlog of all changes since last release, generated by:
git shortlog ${LAST_RELEASE}...
11) Add the announcement to the NEWS page and the front page.