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
|
So far, cairo hasn't reached an initial release. But we can still form
good habits now by practicing the release process with the current
snapshots.
A new snapshot is needed whenever significant new features or bug
fixes are committed. Here are the steps to follow:
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:
caioo-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
snapshot. Summarize major changes briefly in a style similar
to other entries in NEWS. Take special care to note any
incompatible changes 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 snapshot tag:
cvs diff -r SNAPSHOT_X_Y_Z src/*.h
[Hmm, it would be nice to have a pattern for that command that
would exclude private header files.]
4) Increment CAIRO_VERSION in configure.in
First, remove the "-head" suffix, then increment the version
as follows:
If there are backward-incompatible changes in the API,
(function removals, or semantic changes), increment the minor
number and reset the sub-minor number to 0.
Otherwise, (that is, if there are only bug fixes and perhaps
API additions), then increment only the sub-minor number.
Prior to the initial "1.0" release of cairo, leave the major
number at 0. Also, do not modify the "libtool shared library
version" variables, (LT_CURRENT, LT_VERSION, LT_AGE).
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 no release exists with the current version
* Verify that make distcheck completes successfully
* Generate the final tar file
* Generate an md5sum file
* scp both files to appear on http://cairographics.org/snapshots
* Create a LATEST-package-version file (after deleting any old one)
* Place local copies of both files in the releases directory
* Provide some text for the release announcement (see below).
7) Tag the entire source tree with a tag of the form SNAPSHOT_X_Y_Z:
cvs tag SNAPSHOT_X_Y_Z
8) Add a "-head" to CAIRO_VERSION in configure, and commit.
9) Send a message to cairo-announce@cairographics.org and CC
gnome-announce-list@gnome.org to announce the
new snapshot using the text provided from "make release-publish".
|
