Hopefully this is the final commit for 3.0.0.

git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4313

diff --git a/NEWS b/NEWS
index b43998e9bcf092948a6dc2d2f7a53a5c3f130859..92dfa568a4a25dfd4e142be5fa408b7165fd92aa 100644 (file)
--- a/NEWS
+++ b/NEWS
@@ -149,7 +149,8 @@ BUGS FIXED:
 101543  Support fadvise64 syscalls
 75247   x86_64/amd64 support (the biggest "bug" we have ever fixed)
 
-(3.0RC1: 27 July 05, vex r1303, valgrind r4283).
+(3.0RC1: 27 July   05, vex r1303, valgrind r4283).
+(3.0.0:   3 August 05, vex r1313, valgrind r4313).
 
 
 

diff --git a/configure.in b/configure.in
index 4bc6ca01b127d7ea425ec80ba1ed8c022750d546..2bf398f2938aedaa9eca92326940eddf8ee5a566 100644 (file)
--- a/configure.in
+++ b/configure.in
@@ -1,5 +1,5 @@
 # Process this file with autoconf to produce a configure script.
-AC_INIT(Valgrind, 3.0.RC1, valgrind-users@lists.sourceforge.net)
+AC_INIT(Valgrind, 3.0.0, valgrind-users@lists.sourceforge.net)
 AC_CONFIG_SRCDIR(coregrind/m_main.c)
 AM_CONFIG_HEADER(config.h)
 AM_INIT_AUTOMAKE

diff --git a/docs/internals/release-HOWTO b/docs/internals/release-HOWTO
index 92a6182b7c5ca392c759b35b81feb26afa4e0655..3dd4537f3ca884118432e17f697f170bf9e71f80 100644 (file)
--- a/docs/internals/release-HOWTO
+++ b/docs/internals/release-HOWTO
@@ -15,8 +15,20 @@ First of all:
   of tasks for the official release.)
 
 - Write release notes, add to NEWS.  Include a list of fixed bugs from
-  Bugzilla.  [[We should decide a defined way of obtaining this list so it's
-  consistent and so we don't have to work it out anew each time.]]
+  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.
 
 - Other files that might need updating:  README, README_DEVELOPERS,
   README_PACKAGERS.