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