(mysql.info.gz) Release philosophy

 
 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.   Bugs.
 
 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 of them.
 
 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 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.  
      Bugs.
 
    * 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 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 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://dev.mysql.com/', we send
      out an announcement message to the `mysql' and `announce' mailing
      lists.   Mailing-list.  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
      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, despite our best efforts, we get any bug reports after the
      release is done that there was something critically wrong with the
      build on a specific platform, we will fix it 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 fewer than 10
      releases. 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.gz) Many versions
(mysql.info.gz) Which version
(mysql.info.gz) MySQL binaries
automatically generated byinfo2html