summaryrefslogtreecommitdiff
path: root/RELEASING
blob: c6513f451bb3750cbf763925f771b7c83fadfd96 (plain)
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
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 to announce the
   new snapshot using the text provided from "make release-publish".