开发者须知¶

本文档适用于对 bottle 的开发和发布流程感兴趣的开发者和软件包维护者。如果您想贡献代码，来这里就对了！

参与其中¶

有几种方式可以加入社区并保持更新。以下是其中一些：

Bottle 的开发仓库和问题跟踪器都托管在 github。如果您计划贡献，最好在那里创建一个账号并 Fork 主仓库。这样，您的改动和想法对其他开发者是可见的，并且可以公开讨论。即使没有账号，您也可以克隆仓库或直接下载最新的开发版本源码压缩包。

Bottle 不定期发布，并通过 PyPI 发布。候选发布版本仅可从上述 Git 仓库获取。Debian 和许多其他 Linux 发行版提供软件包。

Bottle 版本号分为三个部分（major.minor.patch），但并非遵循 SemVer 的规则。您可以通常依赖以下规则：

主要版本 (x.0): 主要版本号在重要的里程碑事件发生时增加，这些事件会改变框架核心部分的设计，并在某些根本方面破坏向后兼容性。您可能需要修改应用程序的一部分才能使用新的主要版本。不过，这种发布非常罕见。
次要版本 (x.y): 当 API 或行为以某种向后不兼容的方式改变，或添加了主要功能或新 API 时，次要版本号会增加。您可能会收到一些弃用警告，并且可能需要调整一些配置设置以恢复旧行为，但在大多数情况下，这些更改设计为至少在一个次要版本中向后兼容。您应该更新以保持最新，但不是必须的。
补丁 (x.y.z): 补丁版本号在错误修复和其他不改变 API 或行为的补丁发布时增加。您可以安全地更新，无需修改您的应用程序代码。事实上，您应该尽快更新，因为重要的安全修复就是通过这种方式发布的。
预发布版本: 候选发布版本通过版本号中的 rc 标记。它们大多数时候 API 稳定并可用于测试，但尚未正式发布。您不应将它们用于生产环境。

源码仓库结构如下：

master 分支: 这是集成、测试和开发分支。所有计划包含在下一发布版本中的改动都会合并到这里进行测试。
release-x.y 分支: 一旦 master 分支（几乎）准备好进行新发布，就会分出一个新的发布分支。这个“候选发布版本”是特性冻结的，但在被视为可用于生产并正式发布之前，可能会接收错误修复和临时更改。从那时起，它被称为“维护分支”，并且仍然接收错误修复，但仅限于重要的错误。每次推送到这些分支时，补丁版本号都会增加，因此您可以及时了解重要的更改。
特性分支: 所有其他分支都是特性分支。它们基于 master 分支，并且仅在它们仍然活跃且尚未合并回 master 之前存在。

这对开发者意味着什么？

如果您想添加新特性，请从 master 创建一个新的特性分支。如果您想修复错误，请针对每个受影响的发布版本，从 release-x.y 分支。请为每个特性或错误使用单独的分支，以便尽可能简化集成工作。

这对维护者意味着什么？

关注标签（和邮件列表）以获取错误修复和新版本。如果您想从 Git 仓库获取特定发布版本，请信任标签，而不是分支。分支可能包含尚未发布的变化，但标签标记了更改版本号的确切提交（commit）。

将您的更改集成到主开发分支的最佳方法是：在 github 上 Fork 主仓库，创建一个新的特性分支，应用您的更改并发送 Pull Request。本页下方有一个小节，提供了一些 Git 工作流程示例，可以为您提供指导。通过邮件列表提交 Git 兼容的补丁也是可以的。无论如何，请遵循一些基本规则：

文档： 告诉我们您的补丁做了什么。注释您的代码。如果您引入了新特性，请更新文档，以便其他人了解它。
测试： 编写测试来证明您的代码按预期工作且没有破坏任何东西。如果您修复了错误，请至少编写一个能触发该错误的测试用例。在提交补丁之前，请确保所有测试都通过。
一次一个补丁： 一次只修复一个错误或添加一个特性。设计您的补丁，使其可以作为一个整体应用。保持您的补丁干净、小巧且集中。
与上游同步： 如果您在处理补丁期间 upstream/master 分支发生了变化，请执行 rebase 或 pull 操作，以确保您的补丁仍然可以无冲突地应用。