go-ipfs引入了一个新的发布周期和过程，以确保更可靠和更频繁的发布!
IPFS正在成长和成熟。我们在网络中看到了越来越多的用户，并且已经意识到有必要升级我们的发布流程，以便定期提供更多生产就绪的产品。我们这样做是因为在最近三个版本中发布了非常多的关键回归(自修复以来)。我们不希望这种情况再次发生，所以我们正在采取保障措施，以最大限度地提高我们在生产之前解决回归问题的能力。（本文由IPFS中国社区编译）
事情是这样的:
go-ipfs 0.4.19在高负荷下使用时存在多重回归:
docker容器中的回归(由#6040引入)，在更多的生产环境中测试go-ipfs docker映像可以捕获该回归。
只有在非常高的负载下才能看到CPU利用率回归。这可以通过在生产负载下进行测试来捕获。
DHT和QUIC模块中的恐慌只在重载时出现。
go-ipfs 0.4.20有一个回归，其中在同一个add命令中添加多个独立文件不起作用(#6254)。之后添加了回归测试，但是如果使用更好的跨应用程序测试，也会发现这一点。
go-ipfs 0.4.21在bitswap中有两个性能回归:
吞吐量回归应该被回归测试捕获(现在已经测试了)，但是如果发布测试过程更长，下游用户几乎肯定会注意到它。
只有>10000个对等点出现的CPU利用率回归。在重负荷下仅在某些生产系统中出现的东西。
我们发现了两个根本原因:
与前几个季度相比，开发速度有所提高，但没有与我们的测试实践相匹配的改进。今年，一些大型的重构软件触碰到了关键，但是测试很差的子系统。
在没有大规模测试或网络模拟基础设施的情况下，go-ipfs的网络规模和生产需求显著增加。在过去，所有的生产规模测试都是通过将自定义go-ipfs构建部署到引导程序或网关并观察其行为来完成的。
为了解决这些问题，我们暂停了所有非bug修复go-ipfs发行版，因为我们改进了测试实践，构建了测试和网络模拟基础设施。这对于确保改进的测试不会成为面对新功能和紧迫的性能改进的次要问题非常重要。
然而，即使使用我们当前的测试实践，这些回归也应该通过严格的发布前测试得到。更好的发布过程(例如，减少补丁发布的能力)还将使我们能够快速发布这些回归的补丁，并使我们的用户能够快速部署这些补丁，而不用担心额外的不相关更改的潜在影响。
因此,除了提高我们的测试,我们引入一个新的发布流程以确保版本已经在尽可能多的测试环境,我们可以迅速释放bug修复不等待一个完整的发布周期。
发布流程的变化
我们对发布流程做了三个具体的修改:
1、为了解决稳定性问题，我们引入了一个新的发布过程，其中包括在各种生产环境中对发布进行广泛的测试——包括使用早期测试人员。
2、为了解决发行速度慢的问题，我们引入了6周的发行周期。
3、为了解决bug修复缓慢的问题，我们已经切换到semver并引入了补丁版本。第一个补丁版本将是0.4.22，下一个特性版本将是0.5.0。
新发布流程
新的发布流程包括5个阶段:
1、自动化测试- go-ipfs CI通过证。
2、内部测试 – 针对IPFS基础架构，内部测试和模拟工具以及Shipyard应用程序测试go-ipfs 。
3、社区开发测试—go-ipfs由社区在开发环境中进行测试。
4、社区产品测试- go-ipfs由社区在生产环境中进行测试。
5、发布 – go-ipfs被释放。
如果我们在发布过程中合并任何重要的修复，我们将从阶段0重新开始，对已经完成一次的阶段进行压缩发布过程。
我们预计1-3阶段平均需要花费一周的时间，这意味着从删减到发布一个新版本需要3周的时间。
阶段0 -自动化测试
当我们努力保持master green时，问题偶尔会被忽略(通常是由于错误的测试或CI中没有注意到的问题)。在我们发布一个分支之前，我们希望master是绿色的。
这是我们派生出一个发行候选版本的阶段。
阶段1 – 内部测试
这个过程的第一个真正的阶段是内部测试。在此阶段，IPFS团队将针对IPFS Shipyard中的应用程序，构建的一些新的测试和仿真基础设施以及IPFS项目生产基础设施的子集(引导程序和网关)测试候选版本。
这个阶段允许我们在要求更广泛的社区开始测试之前，在一个受限的控制范围内快速地发现、诊断和修复问题。
阶段2 – 社区开发测试
在这个阶段，我们向社区宣布即将发布的版本，并要求进行beta测试。这个阶段的存在是为了给一个新的IPFS发布候选版本提供一些尽可能多的环境下的低风险测试。
这也是我们让早期测试人员参与的第一个阶段。在这里，我们要求他们在他们的开发基础设施中测试go-ipfs版本，并与我们一起解决任何问题。
阶段3 – 社区产品测试
一旦go-ipfs发布候选版本在开发环境中进行了全面的测试，我们要求早期测试人员计划的成员将发布候选版本部署到他们生产环境的子集中。这个阶段让我们有机会对生产工作负载进行测试，同时保留快速回滚更改和修复在最终版本发布之前可能出现的任何问题的能力。
阶段4 – 发布
在第4阶段，我们确保更新了所有的文档，删除了最终版本，并将其发布给社区。
早期测试人员计划
我们正在引入一个早期的测试人员程序，该程序允许在生产中使用go-ipfs的团队帮助测试开发和生产环境中发布的go-ipfs候选版本。当我们邀请整个社区来帮助测试版本时，早期测试人员计划的成员直接并积极地参与到每个版本中。
早期的测试人员将把候选版本部署到开发环境和prod环境中，对于他们注意到的任何倒退或性能变化，我们都会得到快速的反馈。这意味着在我们删除正式版本之前，我们可以从老用户那里得到一些快速的反馈，这些老用户可以和我们一起确保新版本不会在他们的系统中引入任何回归。
该计划目前包括:
Infura
Textile
皮纳塔
RTrade (Temporal)
QRI
Siderus
发布周期
由于没有任何新功能，go-ipfs现在大约每6周就会发布一个新版本。具体地说，我们的目标是每隔6周发布一个新版本，然后在预期的3周内运行整个发布过程。
如果发布过程运行在预期的3周以下或以上，无论如何，下一个版本的目标是在6周标记处进行分支。这样，即使我们没有按时发布，我们仍然可以保持6周的发布节奏。
补丁版本
考虑到这个发布过程中增加的结构和广泛的测试，如果出现关键回归，我们需要一种快速发布补丁的方法。如果我们在go-ipfs发行版中修复了一个关键的回归，我们将基于当前的稳定发行版为这个回归创建一个补丁发行版。
这个补丁的发布仍然会经历一个简短的发布测试过程，但我们预计它需要2-3天，而不是几周:
1、不到一天的时间进行内部测试。
2、1-2天由早期测试人员进行产品测试。
注意:此发布过程不引入长期支持版本。补丁将只适用于最新版本，不会被备份。此外，下一个特性版本可能会包含一些额外的bug修复，这些修复在补丁版本中并不重要。
Semver
这个发布过程最终将go-ipfs切换到semver。与许多1.0之前的项目一样，go-ipfs保留了一些较小的版本，用于重大的破坏性更改或重要的里程碑。然而，这意味着我们无法区分真正的补丁版本(应用于前一个版本的bug修复)和特性版本(次要版本)。
这意味着在go-ipfs达到1.0之前:
小版本将不再标志着重大的里程碑或重大的变更。相反，小版本将是普通的特性版本。
补丁发布现在只是以前稳定版本的补丁。
作为一个历史上的小插曲，我们抱着一个有点浪漫的希望，即0.5.0将标志着功能的完整性(“beta”)，并且在那之后的下一个非补丁版本将是1.0。然而，下一个特性版本0.5.0并不意味着任何特殊的东西，也不会是一个重要的里程碑。
沟通
在这个过程中我们有几个沟通点:
当我们删除每个RC时，我们将创建一个相关的GitHub版本。你可以通过以下两种方式来进行:
订阅RSS提要。
订阅在go-ipfs存储库上发布电子邮件通知。
在阶段0，我们将使用版本检查表的副本创建一个问题。
在阶段2，我们将在IRC/Matrix上发布候选版本。
在阶段3，我们将在IRC/Matrix和Twitter上向更广泛的受众宣布发行候选版本。
在阶段4，我们将继续发布一篇博客文章，宣布此次发布的重点。
在哪里可以学到更多
如果您有兴趣了解这个发布过程的实际情况，我们为最新的补丁发布(0.4.22)测试了完整的(而不是补丁)发布过程:#6506。
如果你想阅读官方的发布过程，你可以在docs/release .md中找到。
最后，如果您正在工作中使用go-ipfs，并且希望加入早期测试人员计划，请阅读docs/ early_tests。如果有兴趣，请提交PR加入。
作者：Steven Allen，Alan Shaw，David Dias，Molly Mackinlay
本文由IPFS中国社区编译，原文链接：https://blog.ipfs.io/2019-08-14-ipfs-release-process/
