MySQL リファレンスマニュアル :: 2.2.7 リリース理念 - リリースに既知のバグがない

カスタマサポートリスト、MySQL 社外メーリングリスト、およびバグデータベース（http://bugs.mysql.com/）からバグをモニタする。

有効なバージョンに関して報告されたすべてのバグがバグデータベースに入力される。

バグが修正されると、そのバグのテストケースを作成して、当社のテストシステムに組み込み、バグが再現しないことを確認する（修正済みバグの約 90% にはテストケースがある）。

また、MySQL に追加されるすべての新機能についてテストケースが作成される。

新しい MySQL リリースの作成を開始する前に、MySQL バージョン（3.23.x や 4.0.x など）について報告されたすべての再現可能なバグを確実に修正する。MySQL の内部の設計上のなんらかの決定が理由で修正が不可能なバグがある場合は、そのことをマニュアルに記載する。 See 項1.8.6. 「MySQL の既知のエラーと設計上の問題」。

専用のバイナリがサポートされているすべてのプラットフォーム（15 以上のプラットフォーム）上でビルドを行い、それらのすべてのプラットフォーム上で当社のテストスィートとベンチマークスィートを実行する。

テストまたはベンチマークスィートが失敗したプラットフォームのバイナリは公開されない。ソースの一般的なエラーである場合は、それを修正し、すべてのシステムで最初からビルドとテストを再実行する。

ビルドおよびテストのプロセス（2、3 日を要する）中に、重大なバグ（コアダンプを発生させるバグなど）に関する報告を受け取った場合は、そのバグを修正した上で、ビルドプロセスを再開する。

http://www.mysql.com/ でバイナリを公開した後、mysql と announce のメーリングリストで告知メールを送信する。 See 項1.7.1.1. 「MySQL メーリングリスト」。 告知メッセージには、リリースに対するすべての変更と、リリースに関する既知の問題の一覧が記載される （リリースノートに「既知の問題」のセクションが必要であったのは、ほんの一握りのリリースだけである）。

ユーザが MySQL の最新の機能に迅速にアクセスできるように、4 〜 8 週間ごとに新しい MySQL リリースを行う。 ソースコードのスナップショットは毎日作成され、http://downloads.mysql.com/snapshots.php で公開される。

リリース後に、特定のプラットフォーム上のビルドに（それでも）重大な問題があったというバグレポートを受けた場合は、バグを直ちに修正し、そのプラットフォーム用の新しい 'a' リリースをビルドする。当社の巨大なユーザ基盤のおかげで、問題は迅速に発見される。

当社は、優れたリリースを作成することに関して高い実績を持つ。過去の 150 リリースにおいて、新しいビルドを行う必要があったのは 10 リリース未満である（そのうちの 3 つは、当社のビルドマシンの 1 つで glibc ライブラリに欠陥があったためであった。これを突き止めるのに長い時間を要した）。