mirror of
https://github.com/ioacademy-jikim/debugging
synced 2025-06-08 00:16:11 +00:00
210 lines
7.4 KiB
Plaintext
210 lines
7.4 KiB
Plaintext
-----------------------------------------------------------------------------
|
|
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 docs/xml/vg-entities.xml. (Exact
|
|
release date probably won't be known yet, updating it is in the list below
|
|
of tasks for the official release.)
|
|
|
|
- Make sure __VALGRIND_MAJOR__ and __VALGRIND_MINOR__ are correct
|
|
for the release. (include/valgrind.h)
|
|
|
|
- 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 SVN.
|
|
|
|
- Other files that might need updating: README, README_DEVELOPERS,
|
|
README_PACKAGERS.
|
|
|
|
- Add X.Y.Z and X.Y+1.Z.SVN 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 in AC_INIT() in configure.in to "X.Y.Z-rcN", where
|
|
'N' is the release candidate number.
|
|
|
|
- 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).
|
|
|
|
- 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 in docs/xml/vg-entities.xml for the official release
|
|
date.
|
|
|
|
- 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.
|
|
|
|
- Change release number in AC_INIT() in configure.in to "X.Y.Z".
|
|
|
|
- Make the tarball ("make dist").
|
|
|
|
- Check tarball builds, installs, regtests on platforms of interest.
|
|
If not, fix and repeat until success.
|
|
|
|
- Tag the repositories ("VALGRIND_X_Y_Z" and "VEX_X_Y_Z"). Point the Vex
|
|
external for VALGRIND_X_Y_Z to VEX_X_Y_Z.
|
|
|
|
If it's a X.Y.0 release, make "VALGRIND_X_Y_BRANCH" and "VEX_X_Y_BRANCH"
|
|
branches too. Useful examples (X.Y.0 major release):
|
|
|
|
cd valgrind
|
|
svn copy trunk tags/VALGRIND_3_3_0
|
|
svn copy trunk branches/VALGRIND_3_3_BRANCH
|
|
|
|
cd vex
|
|
svn copy trunk tags/VEX_3_3_0
|
|
svn copy trunk branches/VEX_3_3_BRANCH
|
|
|
|
cd valgrind
|
|
cd tags/VALGRIND_3_3_0
|
|
svn propset svn:externals \
|
|
"VEX svn://svn.valgrind.org/vex/tags/VEX_3_3_0" .
|
|
cd branches/VALGRIND_3_3_BRANCH
|
|
svn propset svn:externals \
|
|
"VEX svn://svn.valgrind.org/vex/branches/VEX_3_3_BRANCH" .
|
|
|
|
(X.Y.Z minor release):
|
|
|
|
cd vex
|
|
svn copy branches/VEX_3_6_BRANCH tags/VEX_3_6_1
|
|
|
|
cd valgrind
|
|
svn copy branches/VALGRIND_3_6_BRANCH tags/VALGRIND_3_6_1
|
|
|
|
cd tags/VALGRIND_3_6_1
|
|
svn propset svn:externals \
|
|
"VEX svn://svn.valgrind.org/vex/tags/VEX_3_6_1" .
|
|
|
|
|
|
|
|
- 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 AC_INIT() in configure.in to "X.Y.Z.SVN", where
|
|
X.Y.Z is one more than the release just done.
|
|
|
|
- Make sure the release notes are present in the NEWS file on the trunk 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.
|