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 (a] 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 Suggestion for next release: when a bug is fixed, update NEWS 44 directly => less chance to forget, and NEWS always up to date 45 in SVN. 46 47 - Other files that might need updating: README, README_DEVELOPERS, 48 README_PACKAGERS. 49 50 - Add X.Y.Z and X.Y+1.Z.SVN versions to Bugzilla. 51 52 - Add "wantedX.Y.Z+1" and "wantedX.Y+1.Z" milestones to Bugzilla. 53 54 - Check whether copyright years need updating. 55 If so, run auxprogs/change-copyright-year in the top of the tree. 56 57 - Consider upgrading the C++ demangler. 58 auxprogs/update-demangler helps with that 59 60 - Contact Gregory Czajkowski ( gregczajkowski (a] yahoo.com ) and ask him 61 to build (make && make check) valgrind with ICC. 62 63 For each release candidate (should do release candidates for feature 64 releases, bug-fix-only releases might not need one): 65 66 - Build. 67 68 - Do pre-release testing: 69 70 * Check it builds and regtests on a vanilla gcc-2.96 / RedHat 7.3 distro. 71 ??? is this really still up to date ??? 72 73 * Check standard build and regtest on the following cpus: 74 x86, sse2 (P4) 75 x86, sse1 (PIII) 76 x86, no sse (eg older VIA C3s, or perhaps even Pentium-MMX) 77 amd64 78 ppc32, altivec 79 ppc32, no altivec (eg old iMac G3s) 80 81 * Check that the regression tests work on all platforms with more self checks: 82 export EXTRA_REGTEST_OPTS="--sanity-level=4 --helgrind:hg-sanity-flags=011111" 83 make regtest 84 85 * check there are no memleaks or similar bugs by running all regtests 86 in an outer/inner setup (see README_DEVELOPERS). 87 88 * Check valgrind-listener works on all archs, also connecting to it 89 from all archs. 90 91 * Check memcheck can run all the insn-set tests. The testsuite 92 only runs those on 'none', but memcheck looks at all primops, and I've 93 been caught out by this before. Basically all the programs in 94 none/tests/{x86,amd64,ppc32}. 95 96 * Check XML output is still readable by Valkyrie and vk_logmerge tools 97 98 * Test with large applications (firefox and OOo 2.0) on all platforms. 99 100 * Run regression tests from gsl-1.6 on all platforms. This is a good, 101 thorough test of FP. Easy, using the scripts auxprogs/gsl16test. 102 103 * s390x: Run regression tests on a z900 machine. That is the oldest 104 supported model and there is no nightly build for it. 105 106 * s390x: Ensure README.s390 is up-to-date and URLs therein are not stale. 107 108 - Change release number in AC_INIT() in configure.in to "X.Y.Z-rcN", where 109 'N' is the release candidate number. 110 111 - Make the tarball ("make dist") and put it on the web somewhere (it doesn't 112 have to be on valgrind.org if another site is easier). 113 114 - Ensure the tarball builds, runs, regtests on the platforms of interest. 115 However redundant this seems, sometimes it can be that a from-the-repo 116 build works whereas a from-the-tarball one doesn't, usually due to some 117 trivial installation problem. 118 119 - Also check the HTML and print docs look sane (eg. links work). And the 120 man pages, esp. that there are no broken references (look for "???"). 121 122 - Announce the release: 123 - Email valgrind-users and valgrind-developers (but not valgrind-announce). 124 - Make clear it's a release candidate. 125 - Make sure you tell everyone where to download from. 126 - Include the release notes in the email (maybe not necessary for release 127 candidates 2+). 128 129 - Wait 2--3 days for feedback. If bugs appear: 130 - Fix them. 131 - Update the bug-fix list in NEWS if necessary. 132 - Do another release candidate. 133 134 135 For the official release: 136 137 - Again, update date in docs/xml/vg-entities.xml for the official release 138 date. 139 140 - Do pre-release testing: 141 - Make sure regtests run ok on all platforms of interest. 142 - Make sure Mozilla and OpenOffice run ok on all platforms of interest. 143 144 - Change release number in AC_INIT() in configure.in to "X.Y.Z". 145 146 - Make the tarball ("make dist"). 147 148 - Check tarball builds, installs, regtests on platforms of interest. 149 If not, fix and repeat until success. 150 151 - Tag the repositories ("VALGRIND_X_Y_Z" and "VEX_X_Y_Z"). Point the Vex 152 external for VALGRIND_X_Y_Z to VEX_X_Y_Z. 153 154 If it's a X.Y.0 release, make "VALGRIND_X_Y_BRANCH" and "VEX_X_Y_BRANCH" 155 branches too. Useful examples (X.Y.0 major release): 156 157 cd valgrind 158 svn copy trunk tags/VALGRIND_3_3_0 159 svn copy trunk branches/VALGRIND_3_3_BRANCH 160 161 cd vex 162 svn copy trunk tags/VEX_3_3_0 163 svn copy trunk branches/VEX_3_3_BRANCH 164 165 cd valgrind 166 cd tags/VALGRIND_3_3_0 167 svn propset svn:externals \ 168 "VEX svn://svn.valgrind.org/vex/tags/VEX_3_3_0" . 169 cd branches/VALGRIND_3_3_BRANCH 170 svn propset svn:externals \ 171 "VEX svn://svn.valgrind.org/vex/branches/VEX_3_3_BRANCH" . 172 173 (X.Y.Z minor release): 174 175 cd vex 176 svn copy branches/VEX_3_6_BRANCH tags/VEX_3_6_1 177 178 cd valgrind 179 svn copy branches/VALGRIND_3_6_BRANCH tags/VALGRIND_3_6_1 180 181 cd tags/VALGRIND_3_6_1 182 svn propset svn:externals \ 183 "VEX svn://svn.valgrind.org/vex/tags/VEX_3_6_1" . 184 185 186 187 - Update website: 188 - Put the tarball up. 189 - Update the docs -- both the tarball'd docs, and the online-readable docs. 190 - Update www.valgrind.org/downloads/current.html. 191 - Update www.valgrind.org/downloads/old.html. 192 - Add a news item to the front page and also to valgrind.org/info/news.html. 193 Include a link to the release notes. Possibly remove any old release 194 notices form the front page. 195 - Update the "release-date" and "release-version" in php/.htconfx. 196 - Other pages that might need updating: downloads/repository.html. 197 198 - Change release number in AC_INIT() in configure.in to "X.Y.Z.SVN", where 199 X.Y.Z is one more than the release just done. 200 201 - Make sure the release notes are present in the NEWS file on the trunk and 202 the branch. 203 204 - Announce the release: 205 - Email valgrind-users, valgrind-developers, and valgrind-announce. 206 - Email Linux Weekly News. 207 - Include the release notes in the email. 208 209 - Go on holiday. 210
