go-ipfs正在引入一个新的发布周期和流程，以保障更可靠和频繁的版本发布!
IPFS日臻完善。 我们看到越来越多的用户在用我们的网络，而且我们也发现目前的版本发布流程有待升级改进，以便定期提供更多完整的完善的版本。 我们这样做是因为我们在最近三个版本中发现了很多技术小问题。 我们不希望这种情况再次发生，因此我们正在制定保障措施，以最大限度地提高我们发布的版本的质量。
以下为发布过的版本中所出现的问题：
go-ipfs 0.4.19在高强度高负载使用时存在多次还原：
docker容器中的还原，可以通过在更多生产环境中测试go-ipfs docker镜像来捕获。
只有在极高负载下才能看到CPU利用率还原，这可以通过在生产负载下进行测试来捕获。
DHT和QUIC模块中的错误仅在高负荷下出现。
go-ipfs 0.4.20存在一个还原，在同一个add命令中添加多个独立文件是不起作用的(#6254)。此后又添加了还原测试，但这也可以通过更好的跨应用程序测试来实现。
go-ipfs 0.4.21在bitswap中有两个性能还原：
应该通过还原测试(现已测试)捕获的吞吐量还原，但几乎可以肯定，下游用户会在更长的发布测试过程中注意到这一点。
CPU利用率还原，仅显示大于10000的对等项。是一种在高负荷下仅在某些生产系统中出现的东西。
我们发现了两个根本原因：
1.与前几个季度相比，开发速度有所提升，但未对我们的测试实践环节进行改进。今年，一些大型的重构软件触碰到了关键点，但测试效果差强人意。
2.在没有大规模测试或网络模拟基础设施的情况下，go-ipfs的网络规模和生产需求显着增加。过去，所有生产规模测试都是通过将自定义go-ipfs构建部署到引导程序或网关并观察其行为来完成的。
为了解决这些问题，我们暂停了所有非bugfix go-ipfs版本，因为我们改进了测试实践并构建了测试和网络模拟基础架构。除了改进我们的测试之外，我们还引入了一个新的发布流程，以确保在尽可能多的环境中测试版本，并且我们可以快速发布错误修复，而无需等待整个发布周期。
发布流程变更
我们对发布过程进行了三项具体更改：
1.为解决稳定性问题，我们引入了一个新的发布流程，涉及在各种生产环境中广泛测试版本 - 包括早期测试人员。
2.为了解决发布速度慢的问题，我们引入了一个为期6周的发布周期。
3.为了解决缓慢修复错误的问题，我们已经切换到semver并引入了补丁版本。 第一个补丁版本为0.4.22，下一个版本将为0.5.0。
新发布流程
新版本发布过程包括5个阶段：
1.自动化测试 - go-ipfs CI通行证。
2.内部测试 - 针对IPFS基础架构，内部测试和模拟工具以及Shipyard(IPFS船坞)应用程序测试go-ipfs。
3.社区开发测试 - go-ipfs由开发环境中的社区进行测试。
4.社区产品测试 - go-ipfs由生产环境中的社区进行测试。
5.发布 - go-ipfs版本最终发布。
预备阶段 - 自动化测试
这是我们分发候选版本的阶段。
第1阶段 - 内部测试
这个过程的第一个阶段是内部测试。在此阶段，IPFS团队将针对IPFS Shipyard中的应用程序，我们正在构建的一些新测试和模拟基础架构以及IPFS项目的生产基础架构(bootstrappers和网关)的子集测试候选版本。
此阶段允许我们在要求更广泛的社区开始测试之前，在受限制的控制范围内快速查找，诊断和修复问题。
第2阶段 - 社区开发测试
在此阶段，我们宣布即将发布的版本以及测试人员。这个阶段的存在是为了给新的IPFS候选版本提供尽可能多的低风险测试。
这也是我们参与早期测试人员计划的第一阶段。 在这里，我们要求他们在其开发基础设施中测试go-ipfs版本，并与我们一起解决任何问题。
第3阶段 - 社区产品测试
一旦go-ipfs发布候选版已经在开发环境中进行了全面测试，我们要求早期测试人员计划的成员将发布候选版本部署到他们的生产环境的子集中。此阶段使我们有机会测试生产工作负载，同时保留快速更改和修复最终版本之前可能出现的任何问题的能力。
第4阶段 - 发布
在第4阶段，我们确保所有文档都已更新，删除最终版本，并向社区公布。
早期测试人员计划
我们正在推出一个早期测试人员计划，该计划允许使用go-ipfs的团队志愿者帮助在开发和生产环境中测试go-ipfs候选版本。 虽然我们邀请整个社区帮助测试版本，但早期测试人员计划的成员能直接参与每个版本。
早期测试人员会将发布候选版本部署到dev和prod环境中，为我们提供有关他们注意到的任何还原或性能变化的快速反馈。 这意味着我们可以在削减正式版本之前从重度用户那里获得一些快速反馈，这些忠实用户可以与我们合作以确保新版本不会在他们的系统中出现问题。
发布周期
任何功能都会冻结，go-ipfs现在大约每6周就会发布一个新版本。具体来说，我们的目标是每6周分出一个新版本，然后在预期的3周内完成发布过程。
如果发布过程在预期的3周内或之后运行，则下一版本的目标是在6周时进行分支，无论如何。这样，即使我们没有如期发布，我们仍然可以保持6周的发布节奏。(四块科技)
