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