l4/pkg/valgrind/src/valgrind-3.6.0-svn/docs/internals/release-HOWTO.txt

   1 -----------------------------------------------------------------------------
   2 TODO list when doing a Valgrind release (with release number "X.Y.Z")
   3 -----------------------------------------------------------------------------
   4
   5 There are two kinds of releases:
   6
   7 - Feature releases:  X.Y.0, which can include new features.
   8
   9 - Bug-fix releases:  X.Y.[12...], which only include bug fixes.
  10
  11
  12 First of all:
  13
  14 - Tell valgrind-developers you want to do a release.  Give a timeframe for
  15   everyone to check in any final features/bug-fixes they want in the
  16   release.
  17
  18 - Go over the docs, make sure they're up to date.
  19
  20 - Update version number and date in docs/xml/vg-entities.xml.  (Exact
  21   release date probably won't be known yet, updating it is in the list below
  22   of tasks for the official release.)
  23
  24 - Make sure __VALGRIND_MAJOR__ and __VALGRIND_MINOR__ are correct
  25   for the release.  (include/valgrind.h)
  26
  27 - Write release notes, add to NEWS.  Include a list of fixed bugs from
  28   Bugzilla.  It's unclear how to do this consistently.  The approach
  29   taken for 3.0.0 was to go to this page in KDE's bugzilla:
  30      http://bugs.kde.org/query.cgi
  31   and to create a search where
  32      "Status and severity" / Status field is set to RESOLVED
  33   and
  34      "Involved People" / Email, bug-owner contains "jseward"
  35   since I believe jseward@acm.org is the owner of all bugs.
  36   This creates a long list of bugs which does not conveniently stop
  37   at the previous release.  Work backwards through this list until
  38   either (1) you run out of patience, or (2) most of the bugs seem
  39   to pertain to previous releases and are now irrelevant.  In short
  40   this is not a very scientific or robust way to collect up all
  41   bugs fixed since last time.
  42
  43 - Other files that might need updating:  README, README_DEVELOPERS,
  44   README_PACKAGERS.
  45
  46 - Add X.Y.Z and X.Y+1.Z.SVN versions to Bugzilla.
  47
  48 - Add "wantedX.Y.Z+1" and "wantedX.Y+1.Z" milestones to Bugzilla.
  49
  50
  51 For each release candidate (should do release candidates for feature
  52 releases, bug-fix-only releases might not need one):
  53
  54 - Build.
  55
  56 - Do pre-release testing:
  57
  58   * Check it builds and regtests on a vanilla gcc-2.96 / RedHat 7.3 distro.
  59
  60   * Check standard build and regtest on the following cpus:
  61        x86, sse2 (P4)
  62        x86, sse1 (PIII)
  63        x86, no sse (eg older VIA C3s, or perhaps even Pentium-MMX)
  64        amd64
  65        ppc32, altivec
  66        ppc32, no altivec (eg old iMac G3s)
  67
  68   * Check that the regression tests work with --sanity-level=4 on all
  69     platforms.
  70
  71   * Check valgrind-listener works on all archs, also connecting to it
  72     from all archs.
  73
  74   * Check memcheck can run all the insn-set tests.  The testsuite
  75     only runs those on 'none', but memcheck looks at all primops, and I've
  76     been caught out by this before.  Basically all the programs in
  77     none/tests/{x86,amd64,ppc32}.
  78
  79   * Check XML output is still readable by Valkyrie and vk_logmerge tools
  80
  81   * Test with large applications (firefox and OOo 2.0) on all platforms.
  82
  83   * Run regression tests from gsl-1.6 on all platforms.  This is a good,
  84     thorough test of FP.  Easy, using the scripts auxprogs/gsl16test.
  85
  86 - Change release number in AC_INIT() in configure.in to "X.Y.Z-rcN", where
  87   'N' is the release candidate number.
  88
  89 - Make the tarball ("make dist") and put it on the web somewhere (it doesn't
  90   have to be on valgrind.org if another site is easier).
  91
  92 - Ensure the tarball builds, runs, regtests on the platforms of interest.
  93   However redundant this seems, sometimes it can be that a from-the-repo
  94   build works whereas a from-the-tarball one doesn't, usually due to some
  95   trivial installation problem.
  96
  97 - Also check the HTML and print docs look sane (eg. links work).  And the
  98   man pages, esp. that there are no broken references (look for "???").
  99
 100 - Announce the release:
 101   - Email valgrind-users and valgrind-developers (but not valgrind-announce).
 102   - Make clear it's a release candidate.
 103   - Make sure you tell everyone where to download from.
 104   - Include the release notes in the email (maybe not necessary for release
 105     candidates 2+).
 106
 107 - Wait 2--3 days for feedback.  If bugs appear:
 108   - Fix them.
 109   - Update the bug-fix list in NEWS if necessary.
 110   - Do another release candidate.
 111
 112
 113 For the official release:
 114
 115 - Again, update date in docs/xml/vg-entities.xml for the official release
 116   date.
 117
 118 - Do pre-release testing:
 119   - Make sure regtests run ok on all platforms of interest.
 120   - Make sure Mozilla and OpenOffice run ok on all platforms of interest.
 121
 122 - Change release number in AC_INIT() in configure.in to "X.Y.Z".
 123
 124 - Make the tarball ("make dist").
 125
 126 - Check tarball builds, installs, regtests on platforms of interest.
 127   If not, fix and repeat until success.
 128
 129 - Tag the repositories ("VALGRIND_X_Y_Z" and "VEX_X_Y_Z").  Point the Vex
 130   external for VALGRIND_X_Y_Z to VEX_X_Y_Z.
 131
 132   If it's a X.Y.0 release, make "VALGRIND_X_Y_BRANCH" and "VEX_X_Y_BRANCH"
 133   branches too.  Useful examples (X.Y.0 major release):
 134
 135     cd valgrind
 136     svn copy trunk tags/VALGRIND_3_3_0
 137     svn copy trunk branches/VALGRIND_3_3_BRANCH
 138
 139     cd vex
 140     svn copy trunk tags/VEX_3_3_0
 141     svn copy trunk branches/VEX_3_3_BRANCH
 142
 143     cd valgrind
 144     cd tags/VALGRIND_3_3_0
 145     svn propset svn:externals \
 146        "VEX svn://svn.valgrind.org/vex/tags/VEX_3_3_0" .
 147     cd branches/VALGRIND_3_3_BRANCH
 148     svn propset svn:externals \
 149        "VEX svn://svn.valgrind.org/vex/branches/VEX_3_3_BRANCH" .
 150
 151   (X.Y.Z minor release):
 152
 153     cd vex
 154     svn copy branches/VEX_3_6_BRANCH tags/VEX_3_6_1
 155
 156     cd valgrind
 157     svn copy branches/VALGRIND_3_6_BRANCH tags/VALGRIND_3_6_1
 158
 159     cd tags/VALGRIND_3_6_1
 160     svn propset svn:externals \
 161        "VEX svn://svn.valgrind.org/vex/tags/VEX_3_6_1" .
 162
 163
 164
 165 - Update website:
 166   - Put the tarball up.
 167   - Update the docs -- both the tarball'd docs, and the online-readable docs.
 168   - Update www.valgrind.org/downloads/current.html.
 169   - Update www.valgrind.org/downloads/old.html.
 170   - Add a news item to the front page and also to valgrind.org/info/news.html.
 171     Include a link to the release notes.  Possibly remove any old release
 172     notices form the front page.
 173   - Update the "release-date" and "release-version" in php/.htconfx.
 174   - Other pages that might need updating:  downloads/repository.html.
 175
 176 - Change release number in AC_INIT() in configure.in to "X.Y.Z.SVN", where
 177   X.Y.Z is one more than the release just done.
 178
 179 - Make sure the release notes are present in the NEWS file on the trunk and
 180   the branch.
 181
 182 - Announce the release:
 183   - Email valgrind-users, valgrind-developers, and valgrind-announce.
 184   - Email Linux Weekly News.
 185   - Include the release notes in the email.
 186
 187 - Go on holiday.