[cairo-commit] pycairo RELEASING,NONE,1.1

[Steve Chaplin]

Committed by: stevech1097

Update of /cvs/cairo/pycairo
In directory gabe:/tmp/cvs-serv10749

Added Files:
	RELEASING 
Log Message:
SC 14/10/2004

--- NEW FILE: RELEASING ---
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.tar.gz is ready for distribution
	================================================

	(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 following command should be examined using the previous
	snapshot tag:

		cvs diff -r SNAPSHOT_X_Y_Z src/cairo.h

4) Increment CAIRO_VERSION in configure.in

	Right now, in its pre-release form, we are incrementing
	CAIRO_VERSION for each snapshot but we are not changing
	the libtool shared library version information. Increment the
	subminor version for bug fixes and backwards-compatible
	additions to the API. Increment the minor number (and reset
	the subminor) for backward-incompatible changes to the API
	(including removals). Leave the major number at 0 until we are
	ready for the first 1.0 release, (at which point these rules
	will change).

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 cairographics.org:/home/www/cairo/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

9) Send a message to cairo-announce at cairographics.org to announce the
   new snapshot using the text provided from "make release-publish".