Golang之go module開發系列二--使用偽版本和GoCenter

Go模塊已經為Go開發帶來了秩序，但也存在一些潛在的混亂。管理模塊尤其是偽版本可能很困難，尤其是在要進行一些最新更改的情況下。

JFrog GoCenter是一個免費的版本話棋模塊倉庫，現在它包含了一些重要的更新，可以幫助你堅持這個最佳實踐。首先讓我們看看偽版本是如何工作的，以及您可以期望從這些更改中得到什么。我們還提供了一些指導，讓您在升級到1.13或更高版本時保持Go的構建工作。

Go 的模塊版本化

對Go模塊進行版本化是一個關鍵特性，它為開發人員提供了一種方法來確保他們的應用程序使用他們想要的依賴項。在對模塊進行版本控制時，應用程序可以指定依賴的模塊版本，因為我們知道模塊版本與其他組件運行時兼容問題。

Go模塊版本是通過在底層源存儲庫中標記其修訂來分配的。go命令使用標準形式vX.Y.Z的語義版本控制,以此來描述模塊的版本。版本號根據API的變化而變化，如下圖：

從這個標準格式中，可以比較模塊版本，以確定哪個應該被認為是最當前的，哪個應該被認為是最不當前的。

使用Pseudo-Versions（偽版本）

版本化的Go模塊是已經發布的，供一般使用的模塊，應該是大多數開發人員的首選。但是，在某些情況下，您不能發布模塊的最新版本。

例如，一個團隊可能需要在開發期間共享一個臨時版本。特別是當一個依賴的項目還沒有發布版本時，所以它還沒有被標記上版本。類似地，您可能需要針對尚未標記(打tag)的提交進行開發。

要使用未標記版本的模塊作為依賴項，必須通過其偽版本標識符引用它。偽版本的格式如下:

偽版本有三種可接受的形式:

· Vx.0.0-yyyymmddhhmms-abcdefxyz，當在目標提交之前沒有使用適當的主版本進行早期版本提交時

· vX.Y.Z-pre.0.yyyymmddhhmms -abcdefxyz。當目標提交之前的最新版本提交是vX.Y.Z-pre時，

· vX.Y.(Z + 1) 0.yyyymmddhhmms -abcdefxyz。當目標提交之前的最新版本提交是vX.Y.Z時，

作為一種最佳實踐，偽版本字符串不應該是手工輸入的。go命令將接受普通的提交散列并自動將其轉換為偽版本。此方法有助于根據生成的時間戳比較修訂。

例如，一個go get命令可能只使用模塊查詢的提交散列(githash):

同時，這里存在無法讓go命令自動生成偽版本存在問題：

·偽版本參與最小版本選擇。如果它的版本前綴不準確，那么偽版本的優先級可能比隨后的版本更高，從而有效地將模塊固定到提交

·偽版本中的提交日期提供了偽版本之間的總順序，因此如果它被編輯，就會打亂順序

盡管有這樣的建議，但有時我們會手工修改的go模塊中可能存在一個偽版本。在其他情況下，完整的偽版本字符串可能由第三方工具生成。

更嚴格的規則Go 1.13

GO的發行版1.12,Go對偽版本引用進行了修改。大多數涉及偽版本的操作都接受版本字符串和日期的任意組合，并且只要該修訂存在，就會解析為基礎修訂(通常是Git提交散列，git hash)。

然而Go 1.13的發布帶來了更嚴格的規則，以解決上面提到的問題。Go 1.13對“Go”命令接受的偽版本進行了限制，使一些以前接受但不規范的版本無效。

現在，go客戶端將針對版本控制元數據對偽版本的不同元素執行一些驗證：

· 版本前綴的格式必須為vX.0.0，或者從命名修訂版本的祖先上的標簽派生，或者從包含命名修訂版本本身上的構建元數據的標簽派生。

· 日期字符串必須與修訂版的UTC時間戳匹配。

· 修訂的簡稱必須使用與go命令生成的字符相同的字符數。（對于git使用的SHA-1散列，為12位數字的前綴。）

· 僅當對應的主要版本需要偽版本，并且僅當基礎模塊沒有go.mod文件時，偽版本才包含“ +不兼容”（ ‘+incompatible’）后綴

· 即使從代理解析了模塊之后，go客戶端也會嘗試從校驗和服務器獲取校驗和內容，該服務器(Go sumdb)將執行相同的偽版本驗證規則，并拒絕提供校驗和內容，防止代理進行偽裝

1.13之前的Go版本不執行有關偽版本組件的這些規則。這意味著，即使用戶不應該手動生成偽版本，也可以在多個偽版本中使用相同的提交哈希，而不會出現任何問題。

如何修復不正確的偽版本

為了遷移到1.13，開發人員必須糾正所有不符合上述要求的偽版本引用。否則go客戶端會標記一個異常:

go get  golang.org/x/sys@v0.0.0-20190726090000-fde4db37ae7a: invalid

pseudo-version: does not match version-control timestamp (2019-08-13T06:44:41Z)

幸運的是，通過創建偽版本引用的go.mod文件很容易做到這一點。

如果go.mod文件require指令的偽版本不正確，可以通過以下方法更正此錯誤：

1. 用提交哈希字符串替換完整的偽版本引用4

運行go mod tidy以使go客戶端執行正確的替換。

[if !supportLists]2.      [endif]如果其中一個傳遞依賴項引用了無效的偽版本，則可以replace在go.mod文件中使用指令來強制更正：

GoCenter 如何應對上述變化

GoCenter的目標是與Go版本無關（即使在1.13之前，我們也支持所有Go模塊版本）。JFrog的社區工程團隊已經對GoCenter進行了重要的更新，以支持Go 1.13的所有版本，我們正在進行進一步的更新，以滿足Go 1.14的要求。

GoCenter現在通過重定向到正確的偽版本來幫助您遵從偽版本驗證。當請求模塊下載錯誤的偽版本時，GoCenter將使用正確的版本修改.info中的元數據。

要使用GoCenter，請設置GOPROXY 

針對Go 1.12

對于Go 1.12用戶，GoCenter將更新Go。用正確的偽版本保存在其存儲庫中的go.mod文件。GoCenter仍將提供在此更改之前在GoCenter中處理的不正確的偽版本。

針對Go 1.13

Go 1.13用戶將收到一條錯誤消息，指出正確的偽版本。

以便在go.mod文件中更新正確的偽版本，Go 1.13用戶只需要改變Go get包含偽版本中的提交哈希（git hash）部分。

如果希望覆蓋此行為并讓GoCenter提供前面處理的錯誤偽版本，則可以設置GOSUMDB= off。

Go 1.14對于Go Module的變更

正如我們所注意到的，JFrog正在修改GoCenter以支持Go 1.14。以下是該版本中可能會影響模塊操作的一些更改，您可能希望了解這些更改:

1. Go命令標志

· go get命令不再接受-mod標志

· 如果沒有頂級供應商目錄并且go.mod文件是只讀的，則默認設置-mod = readonly

· 引入了-modfile = file新標記，該標記指示go命令讀取/寫入備用go.mod文件，還將使用備用go.sum文件。盡管仍必須存在名為go.mod的文件才能確定模塊的根目錄

2.go.mod文件更改

· 除非明確要求或已經要求，go get不會升級到+不兼容的主要版本

· go命令（go mod tidy除外）不會刪除require指令，該指令指定主模塊的其他依賴項已經隱含的間接依賴項的版本

· 設置-mod = readonly標志時，go命令不會因缺少go指令或任何錯誤而失敗

3. 模塊下載

· go命令現在在模塊模式下支持Subversion存儲庫

· Go命令現在包括來自模塊代理和其他HTTP服務器的純文本錯誤消息的摘要。僅當錯誤消息是有效的UTF-8且由壟斷圖形字符和空格組成時，才會顯示錯誤消息。

和GoCenter一起前進

隨著Go模塊獲得更大的接受度，標準肯定會改變。您可以依靠JFrog GoCenter來跟上這些變化，并在需求發展時幫助您克服障礙。

如果你還沒有探索GoCenter的免費Go模塊庫，我們邀請你去探索!它有一個豐富的UI，可以幫助您檢查所有600,000多個Go模塊的數據，可以幫助您獲得對所使用的GoLang依賴項的強大支持。

學習更多技術知識可以關注我們的在線課堂

關注微信公眾號:JFrog杰蛙DevOs, 獲取課程通知