RELEASE-PROCESS

   1 Status
   2 ------
   3
   4 This document, at this point, is a proposal only. It attempts to
   5 document how we intend to make the upcoming releases, in order to make
   6 as sure as possible no stupid bugs creep in just before the release.
   7
   8 Talk to James K. Lowden before releasing next time about how to set up a
   9 release branch.
  10
  11 Contents
  12 --------
  13
  14 When a new version is about to be released:
  15
  16 0) Day Zero (D+0): The core developers announce their intention of
  17    making a new release. They call for a feature freeze on the CVS
  18    HEAD (bug fixes are okay to commit). They also announce the
  19    provisional duration of the freeze before the first release
  20    candidate tarball is about to be made (actual freeze duration may vary for
  21    instance according to the perceived amount of changes since the
  22    last release; for the purpose of this document, it's assumed to be
  23    three days).
  24
  25    Advanced users are encouraged to download the CVS HEAD or the
  26    snapshot tarballs, and pound on them.
  27
  28    Make sure to check for open Bugzilla bugs with the PATCH keyword.
  29
  30 1) The core developers agree on the next version number. It's called
  31    $VERSION thereafter.
  32
  33 2) D+3: a release candidate tarball is made. It is called
  34    $VERSION-pre1. Simultaneously, a CVS tag is made with the name
  35    "DIA_$VERSION_PRE1" (with the non-alphanumeric characters in
  36    $VERSION replaced by underscores). $VERSION-pre1 is registered with
  37    the Bugzilla, however it is encouraged that bug reports are made
  38    directly (or simultaneously) to the mailing list.
  39
  40    Please see the section below on how to make a tarball (yes, please do).
  41
  42    Translators, as pulled from the Translation-Team: field in the .po
  43    files, are notified of the upcoming release to give them time to
  44    translate new strings.  No further changes to translatable strings
  45    should happen from now till the final release ("string freeze").
  46
  47 3a) if a release-critical bug happens before D+10 (say, at D+n), the
  48    release process is paused until the bug is fixed and a new release
  49    candidate tarball $VERSION-pre2 is re-made. Go to either step 3a or
  50    3b with D+10 replaced by D+n+10.
  51
  52 3b) D+10: if there are no release-critical bugs in the pre-release,
  53    then the same source (fetched from the CVS tag) is rebuilt with the
  54    final $VERSION number (and the resulting "new" version is re-tagged
  55    in CVS). $VERSION is registered with the Bugzilla, and all
  56    $VERSION-preX are removed (from now on, bugs against -preX are
  57    rejected as INVALID).
  58
  59 4) once the new release is complete and uploaded, announcements on
  60    freshmeat, the dia web site, the dia mailing list,
  61    gnome-announce-list@gnome.org and maybe a gnotices story
  62    (news.gnome.org) are made.  Alerting the package maintainers for the
  63    various distributions is also a good idea, get names from MAINTAINERS
  64    and update those who have changed.
  65
  66 5) the CVS HEAD freeze is lifted one week /after/ the release is
  67    generally available, unless a release critical bug is discovered in
  68    the release. If the latter is the case, a new, fixed "brown bag" release is
  69    released and announced as soon as possible (extending the one-week
  70    delay on the CVS HEAD thaw).
  71
  72 How to make a tarball
  73 ---------------------
  74   1. make sure you have up to date build tools installed on the system.
  75       Libtool is an important one, as new releases add support for new
  76      platforms.
  77   2. make sure "make distcheck" runs to completion.  With automake >=
  78      1.5, the checks also make sure "make uninstall" removes all files
  79      that got installed.
  80   3. check to see if the tarball builds in normal and --enable-gnome
  81      modes (this task should disapear with the move to 2.0; there is no
  82      reason to have separate dialog and menu code).
  83   4. Upload to ftp.gnome.org.  This is basically just scp'ing the
  84      tarball to widget.gnome.org, then running a command like
  85      "install-module dia-0.90.tar.gz", which will create bz2
  86      tarballs, diffs to the previous version, and signal the ftp mirrors
  87      (currently just ftp.gnome.org and planetmirror.com) to synchronise.
  88
  89 Issues to solve
  90 ---------------
  91
  92 agreeing on how to properly handle the case of having only ten two-decimal
  93 place version numbers until we hit 1.0
  94
  95 Files
  96 -----
  97
  98 These files need to be updated at every release:
  99
 100 config.h.win32
 101 News
 102 configure.in
 103 doc/en/dia-manual.sgml?
 104 dia.spec (note that the preN should go in release, not ver.
 105
 106 Webpages
 107 --------
 108
 109 Remember to also update the webpages.  In particular, the download page,
 110 the NEWS page and the FAQ needs updating.