MySQL Reference Manual for version 4.0.18.
2.1.2.4 Release Philosophy--No Known Bugs in Releases
We put a lot of time and effort into making our releases bug free.
To our knowledge, we have not released a single MySQL version with any
known "fatal" repeatable bugs.
(A fatal bug is something that crashes MySQL under normal usage,
produces incorrect answers for normal queries, or has a security problem.)
We have documented all open problems, bugs, and issues that are
dependent on design decisions.
See section 1.8.7 Known Errors and Design Deficiencies in MySQL.
Our aim is to fix everything that is fixable without risk of
making a stable MySQL version less stable. In certain cases, this
means we can fix an issue in the development versions, but not
in the stable (production) version. Naturally, we document such
issues so that users are aware.
Here is a description of how our build process works:
-
We monitor bugs from our customer support list, the bugs database at
http://bugs.mysql.com/, and the MySQL external mailing lists.
-
All reported bugs for live versions are entered into the bugs database.
-
When we fix a bug, we always try to make a test case for it and
include it into our test system to ensure that the bug will never
recur without being detected. (About 90% of all fixed bugs have a test case.)
-
We also create test cases for all new features we add to MySQL.
-
Before we start to build a new MySQL release, we ensure that all
reported repeatable bugs for the MySQL version (3.23.x, 4.0.x, etc)
are fixed. If something is impossible to fix (due to some internal
design decision in MySQL) we document this in the manual.
See section 1.8.7 Known Errors and Design Deficiencies in MySQL.
-
We do a build on all platforms for which we support binaries (15+
platforms) and run our test suite and benchmark suite on all of them.
-
We will not publish a binary for a platform for which the test or
benchmark suite fails. If it's a general error in the source, we fix
this and do the build plus tests on all systems again, from scratch.
-
The build and test process takes 2-3 days). If we receive a report regarding
a fatal bug during this process (for example, one that causes
a core dump), we fix the problem and restart the build process.
-
After publishing the binaries on http://www.mysql.com/, we send
out an announcement message to the
mysql
and announce
mailing
lists.
See section 1.7.1.1 The MySQL Mailing Lists.
The announcement message contains a list
of all changes to the release and any known problems with the release.
(The "known problems" section in the release notes has only been needed
in a handful of releases.)
-
To quickly give our users access to the latest MySQL features, we do
a new MySQL release every 4-8 weeks.
Source code snapshots are built daily and are available at
http://downloads.mysql.com/snapshots.php.
-
If we, after the release is done, get any bug reports that there was
(after all) anything critically wrong with the build on a specific
platform, we will fix this at once and build a new
'a'
release
for that platform. Thanks to our large user base, problems are found
quickly.
-
Our track record for making good releases is quite good. In the last
150 releases, we had to do a new build for less than 10 releases (in 3
of these cases, the bug was a faulty
glibc
library on one of our build
machines that took us a long time to track down).
This document was generated
by rdg (Feb 25 2004)
using texi2html