maybe we should be doing releases on branches from the trunk so that the package
version in CVS can always be date-generated and core hacking isn't discouraged
during the release cycle.

Release TODO
------------

* make distcheck should pass
* rpms should build
* debs should build

Packaging issues will hopefully be less difficult in the future as the build
system stabilizes.

* after a release, we move in cvs mode and use a .1 nano version number

* close to the next release, we make prereleases by upping the nano version

* update web site release notes

* add release notes to cvs -- why?

* test suite should pass

* autotools have latest config.{guess,sub}
  This is needed in order to support newer platforms.
  On Debian install the autotools-dev package to get these.

* depending on how the API has changed update the libtool versioning
  in configure.ac.  Look at the libtool info page about versioning for
  guidelines.

* update package version

* roll a preliminary distribution tarball, make sure that it installs fine,
registers fine, runs the media tests fine, and uninstalls as well

* tag tree
  http://gstreamer.net/dev/cvs.php
  add tag to above page

* update web site release notes: added to cvs
  - change the releases/current symbolic link
  - text version of release announcement can be made from 
    lynx -dump http://gstreamer.net/releases/current/notice.php?clean=1

* update web site docs
  - release-specific docs should go in CVS
  - change docs/current symlink

* update status table cvs status and then click on the release link
  http://gstreamer.net/admin.php is the portal to all of this

* update web site news items for release
  again, the admin.php page

* upload to sourceforge
  - should we md5 the tarballs?

* announce to:
  freshmeat
  gstreamer-{devel, announce}
  linux-audio-dev (if it's a big release)
  gnome lists (?)
  lwn (if it's a big release)


Should work:

* autoconf feature to allow building outside source dir



Package version policy
----------------------

Use major.minor.micro versioning

Before 1.0.0

Update micro until code and API are fairly stable, then update minor.


After 1.0.0

Update major when code and api hit new level of stability or major features.
Update minor on API changes.
Update micro on API-compatible changes.