小。快。可靠。
三选二。
三选二。
这是 SQLite 的质量管理计划。
质量管理文档往往会扩展成满本的难以理解的术语，没有人会阅读。本文档力求打破这种模式，力求简洁实用。
本文档的灵感来自 DO-178B。在质量标准中，DO-178B 似乎具有最高的实用性与文书工作比。即使如此，全面实施 DO-178B 所需的文档量也是巨大的。SQLite 力求灵活且仪式感少，为此，省略了大部分所需的 DO-178B 文档。我们只保留那些真正能提高像 SQLite 这样的开源软件项目质量的部分。
本文档的目的是向读者简要介绍 SQLite 开发团队如何日常运作，他们不断改进 SQLite 软件并努力提高其已经很高的可靠性。如果一个合格的开发人员在阅读本文档后可以很快地融入开发团队，那么本文档就达到了其目的。
质量管理计划最初是通过浏览 DO-178B 第 11 节（第 48 页至 56 页）中对输出的描述，并写下那些看起来与 SQLite 相关的部分而编写的。该文本将随后修订以跟踪 SQLite 质量流程的改进。
本节是 DO-178B 中“认证软件方面计划”和“软件开发计划”部分的组合。
请参阅 关于 SQLite，以了解 SQLite 软件的概述，以及它的功能、它的不同之处。
SQLite 使用持续集成流程。该软件一直在不断改进和完善。最新的主干代码提交经常被用于内部的关键任务操作。
没有预定义的发布周期。发布发生在有大量功能增强和/或错误修复时。历史上，大约每 5 或 6 个月就会发布一次。SQLite 的用户根据需要从网站获取新版本。
SQLite 的例行维护版本包含功能增强、性能增强和/或对非关键问题的修复。主要版本的版本号格式为“3.N.0”，其中 N 为某个整数。有关详细信息，请参阅 版本编号约定 文档。
即将发布的维护版本将在预期的发布前大约两周在 sqlite-users 和 sqlite-dev 的 邮件列表 上发布。在发布前大约一周，首席开发人员会宣布“停止开发”，之后只允许在主干上进行错误修复提交。会创建一个新的 发布检查表，并在需要时进行更新。随着检查表项目的验证，它们会被勾选，并变为绿色。所有检查表项目都变为绿色时，发布即完成。此流程通常需要大约一周的时间。
偶尔，会发现一个严重的问题，需要对常规维护版本进行一个小型的“修补”版本。修补版本与维护版本的区别在于，与上一个版本相比，更改的代码行数很少。通过确保维护版本没有错误，我们尽一切努力避免修补版本。
修补版本可能会有也可能没有发布检查表，具体取决于问题。这由项目负责人决定。
文档系统会自动维护过去发布的 时间线，以及带有更改摘要的 SQLite 版本的完整列表。
SQLite 有一个长远的愿景。规划是以 SQLite 至少在 2050 年之前将被使用和支持的假设为基础进行的。所有代码都是以这样的理念编写的，即它有一天会被尚未出生的人阅读和维护。代码被仔细注释，目的是帮助这些未来的开发人员更容易地理解代码的逻辑和背后的原理。
SQLite 是用可移植的 C 代码编写的。开发工作是在 Linux、Mac 和 Windows 工作站的混合环境中进行的。开发人员使用命令行工具，尽可能避免使用集成开发环境 (IDE)。所有开发人员都应熟练使用 Unix 命令行。
从规范源代码编译和测试 SQLite 的最小设置如下
Tcl 脚本语言用于帮助将规范源代码转换为 合并文件，并管理测试。Tcl 本身不直接被 SQLite 使用（除非由编译时选项请求）。SQLite 合并文件源代码的最终用户不需要 Tcl。
在构建 CLI 时，如果有以下第三方库，则会有所帮助，但不是必需的
完整的 SQLite 发布测试需要额外的软件，
SQLite 预计在所有现代操作系统、所有现代计算机体系结构以及使用所有现代 C 编译器上都能正常运行，并使用完全相同的 磁盘格式。开发人员不断在尽可能多的不同平台上测试 SQLite。
SQLite 的测试流程在 测试 文档中进行了描述。测试目标包括
测试流程由 发布测试检查表 控制。检查表简明扼要地总结了全面验证 SQLite 所需的所有步骤，并记录了每个验证步骤何时以及由谁执行。
发布检查表项目的集合可能会为每个版本进行更新。每个发布检查表的内容和完整历史记录都将保留在历史记录中。
SQLite 源代码使用 Fossil 版本控制系统进行管理。Fossil 是专门为支持 SQLite 开发而编写的。Fossil 提供分布式版本控制和问题跟踪。
所有代码都保存在三台不同的机器上：https://www.sqlite.org、https://www2.sqlite.org、https://www3.sqlite.org。这些机器位于不同的城市（分别是达拉斯、纽瓦克和旧金山），并由两家不同的托管公司管理（前两台由 Linode 托管，第三台由 Digital Ocean 托管）。这种多样性旨在避免单点故障。
达拉斯的 https://www.sqlite.org/ 主机是主服务器，也是大多数人使用的服务器。另外两台被视为备份服务器。
除了官方代码库之外，开发人员通常会在他们的个人机器上保留所有软件的完整克隆。互联网上还有其他克隆。
SQLite 源代码被分成多个代码库，每个代码库在下面单独介绍。
SQLite 源代码和 TCL 测试套件 存储在一个代码库中。这个代码库是构建 SQLite 所需的全部内容。源代码库是公开的，互联网上的匿名用户可以读取。
文档源代码包括文档文本和图像，以及构建 SQLite 网站文档所需的脚本和 makefile。本文档包含在文档源代码中。文档源代码保存在与源代码不同的代码库中。文档源代码库是公开可读的。
用于生成文档的 makefile 和脚本从文档源代码库中的基线文档中收集文本。从 SQLite 源代码中的注释中提取其他文本。需求覆盖信息是从 TCL 测试套件（它是源代码库的一部分）中的特殊注释中提取的，以及从 TH3 测试套件中的注释中提取的，后者位于单独的私有代码库中。
SQL 逻辑测试 是一组测试用例，旨在表明 SQLite 的行为与其他 SQL 数据库引擎相同。这些测试托管在单独的公共代码库中。
测试套件 #3 或 TH3 测试套件是一组私有测试用例，用于以交付配置测试 SQLite 至 100% MC/DC。TH3 源代码在与其他 SQLite 代码库相同的服务器上提供，但与其他代码库不同，它是专有的。只有 SQLite 开发人员才能访问 TH3 代码。
dbsqlfuzz 模块是 SQLite 的 libFuzzer 基模糊测试器。Dbsqlfuzz 模糊测试 SQL 和数据库文件本身。Dbsqlfuzz 使用定制的变异器。
Dbsqlfuzz 似乎比其他任何模糊测试器都能更好地发现问题。出于这个原因，它被保密。我们不希望黑客获得这项技术的访问权限。
发布测试根据 检查列表 进行。每个检查列表的当前状态和完整的变更历史记录都存储在独立的 SQLite 数据库文件中。这些文件没有进行版本控制，但在私有备份服务器上维护了独立的副本。
运行检查列表的软件源代码存储在位于 https://www.sqlite.org/checklistapp 的独立 Fossil 代码库中。
在 SQLite 项目中，“需求”指的是项目文档。文档文本中的特殊标记标识了各个需求。需求编号基于规范化需求文本的加密哈希值，因此在不改变需求编号的情况下，无法更改需求文本。
文档文本（以及需求文本）来自上述的 SQLite 文档源代码库，以及实现中的注释。用于构建文档的 makefile 位于文档源代码库中。
构建文档时，会识别和标记需求。文档构建过程还会扫描验证每个需求的测试用例，并构建矩阵以显示哪些需求已测试，并标识测试这些需求的特定测试用例。
SQLite 的客观编码标准很少
所有其他设计和编码规则都是主观的。目标是使软件可读且可维护到 2050 年。为此，我们寻求简洁但有用的注释（没有样板代码），精心选择的变量名称以及对每个数据结构的含义和每个代码块的作用的仔细解释。
所有问题都得到迅速解决。SQLite 软件中没有未解决的问题。
SQLite 使用的 Fossil 版本控制系统 包含对跟踪故障单的内置支持。这个内置的故障单系统用于跟踪和记录许多历史问题。
任何人都可以在 SQLite 社区论坛 上询问有关 SQLite 的问题或报告 SQLite 的错误。第三方发现的错误通常最初是在论坛上报告的。论坛上报告的错误有时会被转移到故障单中，尽管最近的做法是直接在论坛上处理错误。论坛拥有出色的全文搜索功能，并被镜像到多台机器上，并且与故障单系统一样可搜索和可生存，因此，似乎没有必要将论坛上起源的错误报告复制到故障单系统中。论坛的公共位置是
与源代码库一样，论坛也同步到各种私有机器上。请注意，由于 Fossil 的工作方式，“备份”不仅仅是只读备份。它们也可以用作数据输入。所有输入的内容都会同步到所有代码库中，无论使用哪个代码库进行插入。