我们应该努力实现快速发布周期，遵循 “语义化版本控制”。唯一不同的是，由于我们尚未通过 1.0.0 版本，因此在引入 API 更改时，我们不会增加主版本。
<何时应该发布
- 在每次“会话”的错误修复之后。这应该增加“修补程序”版本：
x.x.PATCH - 在每次“会话”的功能添加之后。这应该增加“次要”版本，并将修补程序版本设为零：
x.MINOR.0
<工作应该在哪里进行
“master”分支 - 此分支是应该合并所有针对下一个版本的工作的分支。这些应该是修复、小功能或已签名的重要功能。
“feature”分支 - 对于“不太小的功能”，应该创建一个单独的分支，并以该功能命名。此分支应该从“master”分支分支出来，最终将合并到该分支中。
<请求拉取
如果您想开发 CocoaPods 宝石，您需要分叉主仓库，从您的分叉中进行工作，然后创建一个请求拉取。
请求拉取将由至少一名核心团队成员查看。通常会对从代码样式、文档、测试覆盖率和架构等所有内容进行评论。每个请求拉取都会通过 Travis CI 和 Coveralls 运行构建。
测试必须通过才能合并您的请求拉取。对于新功能，必须添加测试。对于删除功能或重大重构，可以删除测试。确保在提交消息或请求拉取描述中注明这一点。
最后，确保使用适当的消息更新 CHANGELOG，并给自己一些荣誉。真棒。