ライブラリとして利用する場合v4.0.4以上のバージョンが利用できない

[MH4GF]

github-nippouを別のGoプログラムから利用する際、以下のような挙動となります。

# バージョン指定なしでgo getする場合、v4.0.4がダウンロードされ、かつ +incompatible が付く
$ go get github.com/masutaka/github-nippou
go: added github.com/masutaka/github-nippou v4.0.4+incompatible

# 最新バージョンのv4.2.7を指定すると以下のエラーが発生し失敗する
$ go get github.com/masutaka/github-nippou@v4.2.7
go: github.com/masutaka/github-nippou@v4.2.7: invalid version: module contains a go.mod file, so module path must match major version ("github.com/masutaka/github-nippou/v4")

proxy.golang.org/を見るとgo getでダウンロード可能なバージョンの一覧を見ることができますが、そこではやはりv4.0.4以降のバージョンは記載されていません。
https://proxy.golang.org/github.com/masutaka/github-nippou/@v/list

v4.0.4の次バージョンであるv4.1.0では、depからGo moduleへの移行が行われています。
#77

達成したいこと

v4.2.7のバージョンや、それ以降のバージョンをgo getで利用できるようにしたいです。
別の解決策として、 go get github.com/masutaka/github-nippou@972d70e87d57346fb1b9ec0bdb7664692c7e2efd のようにコミットハッシュで指定すれば利用できますが、バージョン管理ができないのは望ましくないはずです。

参考

• ref: Proposal: ライブラリとしてのユースケースをサポート #110

[MH4GF]

調査

$ go get github.com/masutaka/github-nippou@v4.2.7
go: github.com/masutaka/github-nippou@v4.2.7: invalid version: module contains a go.mod file, so module path must match major version ("github.com/masutaka/github-nippou/v4")

このエラーは、go.mod ファイルが存在するモジュールのパスが、モジュールのメジャーバージョン（v2以上）と一致していないときに発生します。
Goのモジュールバージョニングポリシーでは、v2以降のメジャーバージョンのモジュールは、モジュールパスの末尾にバージョン番号を含める必要があります。つまりエラーメッセージが示すように github.com/masutaka/github-nippou/v4 としてモジュールのパスを設定する必要があるとのことです。
+incompatible はGo moduleを利用していないGoパッケージを互換性を持たせて読み込ませるための措置とのことです。

ref

• go get の動作メモ — KaoriYa
• Go Modules: v2 and Beyond - The Go Programming Language

解決策案

上記の通りにモジュールパスを github.com/masutaka/github-nippou/v4 にする形で修正し、このコミットで v4.2.8 でgit tagをすると、問題なく読み込むことができました。
master...MH4GF:github-nippou:wip

$ go get github.com/MH4GF/github-nippou/v4

ただ、Makefileのcross-buildなども修正する必要があります。モジュールパスを修正してビルドすると v4 という名前でバイナリが作られてしまいます。
またライブラリのユースケースで利用しているユーザーにとっては破壊的変更となるはずです。
#110 までいなかったため問題ないかとも思いますが...

---

この方針で修正を進めても良いでしょうか？ぜひ議論できると嬉しいです！

[masutaka]

知らなかったです:sweat_drops:
ライブラリの後方互換性を維持するために、このような一見理解しづらい仕様になっているのですね。

README.md からリンクを張っている GoDoc のバージョンが上がらないことと、辻褄が合いました。

🔗 Go Modules: v2 and Beyond - The Go Programming Language

To start development on v2 of github.com/googleapis/gax-go, we’ll create a new v2/ directory and copy our package into it.

$ mkdir v2
$ cp -v *.go v2
'call_option.go' -> 'v2/call_option.go'
'gax.go' -> 'v2/gax.go'
'header.go' -> 'v2/header.go'
'invoke.go' -> 'v2/invoke.go'
$

紹介してくれた公式ブログに従うと、v4/ ディレクトリを掘って、既存のコードをコピーする必要があるようですが、今までライブラリとしてのユースケースはないはずなので考えなくて良いと思います。

PR 作りますね。

P.S.
https://github.com/google/go-github を見ると、go.mod はそうなっているのに、v56/ というディレクトリは存在してなくて、まだ理解しきれていません。

[MH4GF]

確認ありがとうございます！
初見だとちょっと理解しづらい仕様ですよね。ソースコード上で複数バージョンのサポートをするためにv2のようなディレクトリを切る形にしており、その理由としてそのパッケージのコードを段階的にアップデートできるようにするためとのことでした。

One of the key reasons to allow both v1 and v2 of a package to coexist in a large program is to make it possible to upgrade the clients of that package one at a time and still have a buildable result. This is specific instance of the more general problem of gradual code repair.

ref: research!rsc: Semantic Import Versioning (Go & Versioning, Part 3)

ただ、git historyが途切れてしまうのはどうなの...とも思いますし、github-nippouは複数バージョンの保守をする予定はないと思うので、特にディレクトリを切る必要はなさそうに思います。

https://github.com/google/go-github を見ると、go.mod はそうなっているのに、v56/ というディレクトリは存在してなくて、まだ理解しきれていません。

よく見ると、go-githubの現在利用しているバージョンはv17.0.0+incompatibleで、最新バージョンはv56なんですね🙄できればあげたいですね。
(余談ですが、ここまでメジャーバージョンが上がっているソフトウェアを初めて見ました 😅 Jestのv29も高いなーと思っていましたが、大幅に超えてきました。)

[masutaka]

git historyが途切れてしまうのはどうなの...とも思いますし、

ですよね。勿体ない:sweat_smile:

github-nippouは複数バージョンの保守をする予定はないと思うので、特にディレクトリを切る必要はなさそうに思います。

ですね。v3 とかのブランチを切って保守する方法が伝統的だと思いますが、今回の方法は初めて知りました。好き好きがありそうだなあ。

go-githubの現在利用しているバージョンはv17.0.0+incompatible

Dependabot にお任せしているのですがね 💦

でもアップデートが来たことがありませんでした。／(^o^)＼
https://github.com/masutaka/github-nippou/pulls?q=is%3Apr+author%3Aapp%2Fdependabot+

[Update] そうか、こうするのか。これは面倒くさい...。一度やれば Dependabot に任せられるのかしら？

import (
	"github.com/google/go-github/v56/github"
)

[masutaka]

動作確認結果

以下のような簡単な main.go ファイルを作って、動作確認しました。良さそうです。

package main

import (
	"fmt"

	"github.com/masutaka/github-nippou/v4/lib"
)

func main() {
	fmt.Println(lib.Version)
}

$ pwd
/Users/masutaka/src/github.com/masutaka/test-nippou
$ go mod init
$ go mod tidy
$ ./test-nippou
4.2.8

Go Reference

URL 変わるのですね。なるほど。

https://pkg.go.dev/github.com/masutaka/github-nippou
↓
https://pkg.go.dev/github.com/masutaka/github-nippou/v4

README.md の badge も c948349 で更新しました。

proxy.golang.org

v4 系が全部取れました:hugs:

https://proxy.golang.org/github.com/masutaka/github-nippou/@v/list
↓
https://proxy.golang.org/github.com/masutaka/github-nippou/v4/@v/list

[masutaka]

@MH4GF 問題なければ、クローズお願いします:pray:

[masutaka]

v3 とかのブランチを切って保守する方法が伝統的だと思いますが、今回の方法は初めて知りました。好き好きがありそうだなあ。

そういえば go-yaml はブランチ方式を使ってました。現在のデフォルトブランチは v3 です。
https://github.com/go-yaml/yaml
💭 これも上げよう

[masutaka]

🚀 v4.2.9

[MH4GF]

ご対応ありがとうございました 😄 手元でも適切にgo getできることを確認できました！これでforkではなく本家のコードを利用できるので嬉しいです！！改めて一連の対応ありがとうございました！！！

[MH4GF]

📝 dependabotでgoのメジャーバージョンを上げられない問題気になって調べたのですが、やはりimport文の更新がネックなようですね。今まではgo.modとgo.sumだけdependabotが読んでいればよかったのが、import文を書き換えるためにリポジトリ全体をcloneする必要があるとのこと。

• Major version updates for Go modules dependabot/dependabot-core#2213
• Dependabot updates major +incompatible versions for go modules dependabot/dependabot-core#4453

goのupstreamでもissueが立っていて、自動で更新できる方法を探っているようでした。

• x/tools: automate major version upgrades for modules golang/go#32014