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/
