Status
------

This document, at this point, is a proposal only. It attempts to
document how we intend to make the upcoming releases, in order to make
as sure as possible no stupid bugs creep in just before the release.

Contents
--------

When a new version is about to be released:

0) Day Zero (D+0): The core developers announce their intention of
   making a new release. They call for a feature freeze on the CVS
   HEAD (bug fixes are okay to commit). They also announce the
   provisional duration of the freeze before the first release
   candidate tarball is about to be made (actual freeze duration may vary for
   instance according to the perceived amount of changes since the
   last release; for the purpose of this document, it's assumed to be
   three days).

   Advanced users are encouraged to download the CVS HEAD or the
   snapshot tarballs, and pound on them.

1) The core developers agree on the next version number. It's called
   $VERSION thereafter. 

2) D+3: a release candidate tarball is made. It is called
   $VERSION-pre1. Simultaneously, a CVS tag is made with the name
   "DIA_$VERSION_PRE1" (with the non-alphanumeric characters in
   $VERSION replaced by underscores). $VERSION-pre1 is registered with
   the Bugzilla, however it is encouraged that bug reports are made
   directly (or simultaneously) to the mailing list.

   Please see the section below on how to make a tarball (yes, please do).

3a) if a release-critical bug happens before D+10 (say, at D+n), the
   release process is paused until the bug is fixed and a new release
   candidate tarball $VERSION-pre2 is re-made. Go to either step 3a or
   3b with D+10 replaced by D+n+10.

3b) D+10: if there are no release-critical bugs in the pre-release,
   then the same source (fetched from the CVS tag) is rebuilt with the
   final $VERSION number (and the resulting "new" version is re-tagged
   in CVS). $VERSION is registered with the Bugzilla, and all
   $VERSION-preX are removed (from now on, bugs against -preX are
   rejected as INVALID).

4) once the new release is complete and uploaded, announcements on
   freshmeat, the dia web site, the dia mailing list,
   gnome-announce-list@gnome.org and maybe a gnotices story
   (news.gnome.org) are made. 

5) the CVS HEAD freeze is lifted one week /after/ the release is
   generally available, unless a release critical bug is discovered in
   the release. If the latter is the case, a new, fixed "brown bag" release is
   released and announced as soon as possible (extending the one-week
   delay on the CVS HEAD thaw).

How to make a tarball
---------------------
  1. make sure you have up to date build tools installed on the system.
      Libtool is an important one, as new releases add support for new
     platforms.
  2. make sure "make distcheck" runs to completion.  With automake >=
     1.5, the checks also make sure "make uninstall" removes all files 
     that got installed.
  3. check to see if the tarball builds in normal and --enable-gnome
     modes (this task should disapear with the move to 2.0; there is no
     reason to have separate dialog and menu code).
  4. Upload to ftp.gnome.org.  This is basically just scp'ing the
     tarball to widget.gnome.org, then running a command like
     "install-module --package dia-0.90.tar.gz --old
     dia-0.88.1.tar.gz", which will create bz2 tarballs, diffs to the
     previous version, and signal the ftp mirrors (currently just
     ftp.gnome.org and planetmirror.com) to synchronise.  

Issues to solve
---------------

agreeing on how to properly handle the case of having only ten two-decimal
place version numbers until we hit 1.0 

Files
-----

These files need to be updated at every release:

config.h.win32
News
configure.in
doc/en/dia-manual.sgml?
dia.spec

Webpages
--------

Remember to also update the webpages.  In particular, the download page,
the NEWS page and the FAQ needs updating.
