如何在具有向后標記版本的 Github 上修復 go release 版本控制？

Question

我有一個 Go 模塊發布到 Github。 一開始，我將它標記為v1.0.0，它在我直接從 Github 導入該模塊的主程序上完美運行。

但在接下來的版本中，我已經落后標記它v.0.1.1，因為我覺得我的模塊還不穩定- >（基於語義版本不穩定的版本必須與0.xy開始）。

這在今天成為一個問題，因為我使用 golint 和這個工具，它說go-mod-outdated 。 目前，版本是 v0.5.x 並且在它之前有很多版本（在我使用 lint 和一些 lint 工具之前）

任何想法來解決它？

Answer 1

事情的Semver方面

根據 semver 的說法，根據規范第 9 項，可以使用連字符標記不穩定的較新版本

預發布版本可以通過在補丁版本之后立即附加連字符和一系列點分隔標識符來表示。 標識符必須僅包含 ASCII 字母數字和連字符 [0-9A-Za-z-]。 標識符不得為空。 數字標識符不得包含前導零。 預發布版本的優先級低於相關的普通版本。 預發布版本表示該版本不穩定並且可能不滿足其關聯的正常版本所表示的預期兼容性要求。 示例：1.0.0-alpha、1.0.0-alpha.1、1.0.0-0.3.7、1.0.0-x.7.z.92、1.0.0-xyz.–。

所以這里的問題是你改變了什么？ 如果您剛剛添加了一些功能，但沒有對 API 引入任何重大更改，則應將不穩定版本標記為： v1.1.0-alpha.1 。 然后可以將不穩定版本的修復標記為v1.1.0-alpha.2等等。

如果您以v2.0.0-alpha.1方式更改了包的 API，則該版本應標記為v2.0.0-alpha.1 。 對 alpha 的修復應以與以前相同的方式進行標記：增加-alpha后綴后的最后一位數字。

最后，如果您沒有以任何方式更改 API，也沒有添加任何功能，那么您只需將您的版本標記為v1.0.1-alpha 。 基本上，標准的semver東西。
當然，如果您處於這種特殊情況，那么事實是您過早地將您的軟件包標記為v1.0.0 ，因為推送補丁仍然會導致不穩定。

您可以通過刪除標記來尋址/重新標記現有的v1.0.0版本，並相應地標記該版本。 這可以使用以下命令輕松完成：

# check out the version to re-tag
$ git checkout v1.0.0
# tag the version with the desired tag
$ git tag v0.1.1
# push the tag
# if you're brave, you could just git push --tags, but that's not ideal
$ git push origin v0.1.1
# now delete the offending tag
$ git tag -d v1.0.0
# remove the tag remotely
$ git push origin :refs/tags/v1.0.0

好的，github 倉庫不再有v1.0.0標簽。 存儲庫的任何克隆可能仍然具有舊標簽，如果有人推送git push --tags ，那將恢復v1.0.0標簽（因此我的評論說git push --tags並不理想）。 如果您的包被廣泛使用，這需要與包的所有用戶進行一些溝通。

最后，繼續前進，你最好閱讀一下go mod如何處理版本（它的要點是：遵循 semver 2.0，你應該沒問題）。 偽發布和預發布具有您應該使用的特定格式

Golang (go mod) 細節

一旦模塊被標記並發布，它就在那里。 你應該做的是使用retract指令retract損壞的版本

你說你現在使用的是v0.5.x版本，你發布的下一個版本應該在go.mod文件中包含以下內容：

retract (
    v1.0.0
)

發布您的樂觀標記版本的撤回。 例如，如果您將此版本重新標記為v0.1.0 ，那么您可以使用replace指令。 老實說，我從未使用replace將我的模塊的一個版本指向同一模塊的另一個版本，但這可能值得一試：

replace (
    github.com/your/package v1.0.0 => github.com/your/package v0.1.0
)

我必須說：即使這行得通，它也是一種黑客行為，我不能保證它在發布新版本的軟件包時能很好地發揮作用。 我強烈建議你發布v1.0.0標簽的收回，重新標記它（可以說v0.0.0是這里使用的版本），從現在開始，遵循 semver 和 golang pre-release/pseudo -發布版本控制標准。