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周的釋出節奏。
