我们投入了大量的时间和工作来使我们的发布没有缺陷。我们从来没有发布过含有已知致命重复性缺陷的单一MySQL版本。(“致命”缺陷指能在正常应用中导致MySQL瘫痪的缺陷，对于正常查询产生错误答案，或有安全问题）。
我们已经将所有公开问题、缺陷和由设计决策决定的事宜记入文件。请参见A.8节，“MySQL中的已知事宜”。
我们的目标是修复一切可以修复的东西，而不会使稳定的MySQL版本变得不稳定。在某些情况，这意味着我们可以在开发版本中修复问题，而不是在稳定的 (产品) 版本。自然，我们会将这些问题记入文档，以便用户能知道。
下面描述了我们如何操作：
· 我们通过我们的客户支持列表、在http://bugs.mysql.com/ 缺陷数据库和MySQL外部邮件列表来监控缺陷。
· 当前版本中所有被报导的缺陷被输入缺陷数据库。
· 当我们修复缺陷，我们总是为其设计一次测试案例，并将其包括进测试系统中，以确保不会漏检使缺陷再现。(所有修复的缺陷中大约90%的具有测试案例）。
· 为添加到MySQL中的所有新功能创建测试案例。
· 我们开始构建新的MySQL发布前，我们确保修复了MySQL版本(3.23.x、4.0.x、4.1.x、5.0.x等等)中所有被报导的重复性缺陷。如果某些内容不能修复(由于MySQL内部的一些设计决策)，我们在本手册中记录下来。请参见A.8节，“MySQL中的已知事宜”。
· 我们在所有支持二进制的平台(15+平台)上构建并运行我们的测试套件和基准套件。
· 如果在某个平台上测试或基准套件失败，我们不会公布二进制。如果问题是由于源码中的普通缺陷，我们将进行修复并在所有系统上构建并测试。
· 构建和测试过程需要2-3天。如果在该过程中我们收到致命缺陷相关报告(例如，会造成内核转储)，我们将修复该问题并重新启动构建过程。
· 在http：//dev.mysql.com/上公布二进制后，我们则向mysql发出公告消并announce邮件列表。请参见1.7.1.1节，“The MySQL邮件列表”。公告消息包含所有发布的更改列表和已知问题。只有部分发版不需要已知的问题部分。
· 为了让我们的用户快速访问最新MySQL功能，我们每4-8周产生一个新的MySQL发布。每天构建源码快照，可以从http://downloads.mysql.com/snapshots.html获得。
· 如果，尽管经过我们最大的努力，我们在发布后仍收到缺陷报告，即在某个具体平台上出现严重问题，我们将立即进行修复，并为该平台构建一个新的 'a'版本。由于我们的大用户群，可以很快地查出并解决此类问题。
· 我们为保证稳定版本所做的跟踪记录不错。在最近150个发布中，我们只需要对其中不到10个重新构建。其中有3个案例，缺陷为我们的构建机器上的glibc 库，花了很长时间来跟踪。