| |
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 Section A.8, “Known Issues in MySQL”.
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 https://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 Section A.8, “Known Issues in MySQL”.
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
https://dev.mysql.com/, we send out an
announcement message to the mysql and
announce mailing lists. See
Section 1.7.1, “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 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
https://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.
|
|
