(mysql.info) release-philosophy
Info Catalog
(mysql.info) many-versions
(mysql.info) which-version
(mysql.info) mysql-binaries
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. We
haven't 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 bugs.
Our aim is to fix everything that is fixable without 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 of
them.
Here is a description of our build process:
* 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 can never
recur without being detected. (About 90% of all fixed bugs have
test cases.)
* We create test cases for each new feature that we add to MySQL.
* Before we start to build a new MySQL release, we ensure that all
reported repeatable bugs for that MySQL version (3.23.x, 4.0.x,
4.1.x, 5.0.x, 5.1.x, and so on) are fixed. If something is
impossible to fix due to some internal design decision in MySQL,
we document this in the manual. See bugs.
* We do a build on all platforms for which we support binaries and
run our test suite and benchmark suite on all of them.
* We do not publish a binary for a platform for which the test or
benchmark suite fails. If the problem is due to a general error in
the source, we fix it and do the build plus tests on all systems
again from scratch.
* The build and test process takes a week. 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://dev.mysql.com/', we send
out an announcement message to the `mysql' and `announce' mailing
lists. See 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 been needed for only a handful of releases.
* To quickly give our users access to the latest MySQL features, we
try to produce 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, despite our best efforts, we receive any bug reports after a
release is issued that a critical problem exists for the build on
a specific platform, we fix it at once and build a new `'a''
release for that platform. Thanks to our large user base, problems
are found and resolved very quickly.
* Our track record for making stable releases is quite good. In the
last 150 releases, we had to do a new build for fewer than 10 of
them. In three 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.
Info Catalog
(mysql.info) many-versions
(mysql.info) which-version
(mysql.info) mysql-binaries
automatically generated byinfo2html