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 configure.ac. Probably just the
  21   v_suffix_ver, set it to RC1. The v_rel_date probably won't be known yet,
  22   updating it is in the list below of tasks for the official release.
  23   Note that the date MUST be quoted with ["...date string..."].
  24
  25 - Make sure the after ./autogen.sh && ./configure
  26   __VALGRIND_MAJOR__ and __VALGRIND_MINOR__ are correct for the release.
  27   (include/valgrind.h)
  28   And that docs/xml/vg-entities.xml contains the correct release number
  29   and release date.
  30
  31 - Write release notes, add to NEWS.  Include a list of fixed bugs from
  32   Bugzilla.  It's unclear how to do this consistently.  The approach
  33   taken for 3.0.0 was to go to this page in KDE's bugzilla:
  34      http://bugs.kde.org/query.cgi
  35   and to create a search where
  36      "Status and severity" / Status field is set to RESOLVED
  37   and
  38      "Involved People" / Email, bug-owner contains "jseward"
  39   since I believe jseward@acm.org is the owner of all bugs.
  40   This creates a long list of bugs which does not conveniently stop
  41   at the previous release.  Work backwards through this list until
  42   either (1) you run out of patience, or (2) most of the bugs seem
  43   to pertain to previous releases and are now irrelevant.  In short
  44   this is not a very scientific or robust way to collect up all
  45   bugs fixed since last time.
  46
  47   Suggestion for next release: when a bug is fixed, update NEWS
  48   directly => less chance to forget, and NEWS always up to date
  49   in GIT.
  50
  51 - Other files that might need updating:  README, README_DEVELOPERS,
  52   README_PACKAGERS.
  53
  54 - Add X.Y.Z and X.Y+1.Z.GIT versions to Bugzilla.
  55
  56 - Add "wantedX.Y.Z+1" and "wantedX.Y+1.Z" milestones to Bugzilla.
  57
  58 - Check whether copyright years need updating.
  59   If so, run  auxprogs/change-copyright-year  in the top of the tree.
  60
  61 - Consider upgrading the C++ demangler.
  62   auxprogs/update-demangler   helps with that
  63
  64 - Contact Gregory Czajkowski ( gregczajkowski@yahoo.com ) and ask him
  65   to build (make && make check) valgrind with ICC.
  66
  67 For each release candidate (should do release candidates for feature
  68 releases, bug-fix-only releases might not need one):
  69
  70 - Build.
  71
  72 - Do pre-release testing:
  73
  74   * Check it builds and regtests on a vanilla gcc-2.96 / RedHat 7.3 distro.
  75   ??? is this really still up to date ???
  76
  77   * Check standard build and regtest on the following cpus:
  78        x86, sse2 (P4)
  79        x86, sse1 (PIII)
  80        x86, no sse (eg older VIA C3s, or perhaps even Pentium-MMX)
  81        amd64
  82        ppc32, altivec
  83        ppc32, no altivec (eg old iMac G3s)
  84
  85   * Check that the regression tests work on all platforms with more self checks:
  86      export EXTRA_REGTEST_OPTS="--sanity-level=4 --helgrind:hg-sanity-flags=011111"
  87      make regtest
  88
  89   * check there are no memleaks or similar bugs by running all regtests
  90     in an outer/inner setup (see README_DEVELOPERS).
  91
  92   * Check valgrind-listener works on all archs, also connecting to it
  93     from all archs.
  94
  95   * Check memcheck can run all the insn-set tests.  The testsuite
  96     only runs those on 'none', but memcheck looks at all primops, and I've
  97     been caught out by this before.  Basically all the programs in
  98     none/tests/{x86,amd64,ppc32}.
  99
 100   * Check XML output is still readable by Valkyrie and vk_logmerge tools
 101
 102   * Test with large applications (firefox and OOo 2.0) on all platforms.
 103
 104   * Run regression tests from gsl-1.6 on all platforms.  This is a good,
 105     thorough test of FP.  Easy, using the scripts auxprogs/gsl16test.
 106
 107   * s390x: Run regression tests on a z900 machine. That is the oldest
 108     supported model and there is no nightly build for it.
 109
 110   * s390x: Ensure README.s390 is up-to-date and URLs therein are not stale.
 111
 112 - Change release number (v_major_ver, v_minor_ver, v_micro_ver)
 113   in configure.ac, set v_suffix_ver to RCN, where 'N' is the release
 114   candidate number. Don't forget to ./autogen.sh and ./configure afterwards.
 115
 116 - Make the tarball ("make dist") and put it on the web somewhere (it doesn't
 117   have to be on valgrind.org if another site is easier).
 118   https://sourceware.org/pub/valgrind/ is the default release site now.
 119   You need a shell account on sourceware.org, then scp it with:
 120   scp valgrind-X.YY-RCN.tar.bz \
 121     USER@sourceware.org:/sourceware/ftp/pub/valgrind/
 122
 123 - Ensure the tarball builds, runs, regtests on the platforms of interest.
 124   However redundant this seems, sometimes it can be that a from-the-repo
 125   build works whereas a from-the-tarball one doesn't, usually due to some
 126   trivial installation problem.
 127
 128 - Also check the HTML and print docs look sane (eg. links work).  And the
 129   man pages, esp. that there are no broken references (look for "???").
 130
 131 - Announce the release:
 132   - Email valgrind-users and valgrind-developers (but not valgrind-announce).
 133   - Make clear it's a release candidate.
 134   - Make sure you tell everyone where to download from.
 135   - Include the release notes in the email (maybe not necessary for release
 136     candidates 2+).
 137
 138 - Wait 2--3 days for feedback.  If bugs appear:
 139   - Fix them.
 140   - Update the bug-fix list in NEWS if necessary.
 141   - Do another release candidate.
 142
 143
 144 For the official release:
 145
 146 - Again, update date (v_rel_date) in configure.ac for the official release
 147   date and set v_suffix_ver to empty [] in configure.ac.
 148
 149 - Do pre-release testing:
 150   - Make sure regtests run ok on all platforms of interest.
 151   - Make sure Mozilla and OpenOffice run ok on all platforms of interest.
 152
 153 - Run ./autogen.sh && ./configure && make dist to make the tarball.
 154
 155 - Check tarball builds, installs, regtests on platforms of interest.
 156   If not, fix and repeat until success.
 157
 158 - Tag the repository ("VALGRIND_X_Y_Z").
 159
 160   If it's a X.Y.0 release, make "VALGRIND_X_Y_BRANCH" branch, too.
 161   Useful examples (X.Y.0 major release):
 162
 163     cd valgrind
 164     git checkout HEAD
 165     git tag VALGRIND_3_3_0
 166     git branch VALGRIND_3_3_BRANCH
 167     git push
 168
 169   (X.Y.Z minor release):
 170
 171     cd valgrind
 172     git checkout VALGRIND_3_6_BRANCH
 173     git tag VALGRIND_3_6_1
 174     git push
 175
 176
 177 - Update website:
 178   - Put the tarball up.
 179   - Update the docs -- both the tarball'd docs, and the online-readable docs.
 180   - Update www.valgrind.org/downloads/current.html.
 181   - Update www.valgrind.org/downloads/old.html.
 182   - Add a news item to the front page and also to valgrind.org/info/news.html.
 183     Include a link to the release notes.  Possibly remove any old release
 184     notices form the front page.
 185   - Update the "release-date" and "release-version" in php/.htconfx.
 186   - Other pages that might need updating:  downloads/repository.html.
 187
 188 - Change release number in configure.ac with v_minor_ver one more than the
 189   release just done. Set v_suffix_ver to [GIT].
 190
 191 - Make sure the release notes are present in the NEWS file on the master and
 192   the branch.
 193
 194 - Announce the release:
 195   - Email valgrind-users, valgrind-developers, and valgrind-announce.
 196   - Email Linux Weekly News.
 197   - Include the release notes in the email.
 198
 199 - Go on holiday.