1. The Go gopher was designed by Renée French.
The gopher stickers was made by Takuya Ueda.
Licensed under the Creative Commons 3.0 Attributions license.
Goにおける
バージョン管理の必要性
− vgoについて −
2018/06/14
＠Fukuoka.go#11

2. 自己紹介
上田拓也
@tenntenn
所属
コミュニティ活動
Go ビギナーズ
Go Conference
上田拓也
@tenntenn
株式会社メルペイ
エキスパートチーム
2

3. メルペイ エキスパートチーム
技術をアウトプットするところに技術は集まる
■ エキスパートチームとは？
● 50%以上の時間を技術コミュニティへの貢献に充てる
■ エキスパートチームの役割
● 社内に新しい技術を取り取り込む
● 社外のコミュニティなどを通じて社会へ還元する
■ エキスパートチームの活動
● カンファレンス・勉強会の開催/運営
● 対外的な講演活動
● 執筆、雑誌への寄稿、インタビュー
● 社内外での担当技術の普及推進
@tenntenn
担当：Go・GCP
@mhidaka
担当：Android
メンバー
3

4. vgoとは？
■ 将来的に標準になるであろうバージョン管理ツール
● https://github.com/golang/vgo
● Go1.11（2018年8月予定）でテクニカルレビュー
● Go1.12（2019年2月予定）で正式導入
■ vgoの特徴
● ビルド時に依存関係を解決する（goツールのように）
● ベンダリングが不要になる
● 新しくモジュールという概念単位でバージョン管理する
● 互換性がなくなる場合はインポートパスを変える
● 可能な限り古いバージョンが優先される(Minimal Version Selection)
【参考】
Go & Versioning by Russ Cox
https://research.swtch.com/vgo

5. Go1.0以前の話
■ Makefileを使っていた
● 6g（コンパイラ）や6l（リンカ）を使ってビルド
● サンプルのMakefileが付いていてそれを利用していた
● 依存関係はMakefileの中にかかれていた
● gobuildというラッパーも存在していた
参考：https://ymotongpoo.hatenablog.com/entry/2015/10/13/104247

6. goinstallの登場
■ 2010年2月に登場
■ GitHubやBitbucketからダウンロードして配置する
■ Makefileほどの柔軟性はないが利便性が向上
■ importパスのルールの確立
● ソースコードの中にすべての依存関係が記述される
● go vetなどの静的解析ツールが簡単につくれるようになった
■ 2012年2月のGo1.0リリースでgo getに

7. go getの登場で解決したこと
■ 簡単にビルドができるようになった
■ 作ったものを簡単に公開・再利用できるようになった
● 現在のGoのコミュニティを形成する上で重要なファクター
● go getすることで簡単に他の人が作ったパッケージを利用できる
■ ビルドシステムを意識しなくてよい
● 6gや6lなどを気にしなくてよい
● 依存関係の解決方法などは勝手にやってくれる

8. go getで解決できなかったこと
■ バージョン付けとAPIの安定性
● バージョン付けができない
● アップデートによって何が変わるのかユーザに提示できない
● gopkg.inなどの登場
■ ベンダリングとビルドの再現可能性
● ビルドの再現性がとれない
● 取得時に常に最新を見てしまうこと
● godep、glide、gpなどの登場
● ベンダリングの対応（Go1.5以上）

9. ビルドが解決できない例
D: 1.0
go get D
1. パッケージDのインストール
D: 1.0
go get C
C: 1.8
D≧1.4
2. パッケージCのインストール
D: 1.6
go get -u D
C: 1.8
D≧1.4
3. パッケージDの更新
古
い
※CはDのバージョン1.4以上に依存
バ
グ
うまくビルドができない！

10. depの登場
■ 公式によるバージョン管理の導入の実験
● GopherCon 2016のHack Dayで議論が行われた
● そこからdepが登場した
● https://github.com/golang/dep
■ The New Era of Go Package Management
● GopherCon 2017においての発表
● depのやっていきを発表
● semverの推奨
depはgoツールに
直接導入されるものではなかった

11. そしてvgoへ
■ vgoで提案すること
● Import Compatibility Rule
● Minimal Version Selection
● Go Mobuleの導入
● 現在のワークフローを壊さずにgoツールに導入する

12. Import Compatibility Rule
■ importパスが同じ場合は後方互換性を維持する
● 後方互換性が取れない場合はインポートパスを返す
import "github.com/tenntenn/hoge"
import hoge "github.com/tenntenn/hoge/v2"
後方互換性が担保できない場合

13. Minimal Version Selection
■ 最小バージョンの選択
● 選択できるバージョンのうち最も古いバージョンを選択
● どんどんバージョンアップされても常に同じ（=古い）ものを使う
● 特定のバージョンを指定すれば新しいものを使うことはできる
● 依存モジュールの下限だけ指定することによって、一意にビルドに使用す
るバージョンが特定できる

14. Go Moduleの導入
■ バージョン付けを行う単位
● go.modファイルを使って依存モジュールを記述
● バージョンはsemverで記述する
● 一応特定のコミットも指定できる
// My hello, world.
module "rsc.io/hello"
require (
"golang.org/x/text" v0.0.0-20180208041248-4e4a3210bb54
"rsc.io/quote" v1.5.2
)

15. vgoが普及するために必要なこと
■ vgoが登場した背景の理解
● Go & Versioning を読みましょう
■ semverによるバージョン管理
● 自分のライブラリをsemverで管理しましょう
○ 私もやらなきゃ
● 自分の使ってるライブラリにissueを上げる
https://github.com/golang/appengine/issues/145

16. vgoを体験したければ
■ A Tour of Versioned Go (vgo)
● https://research.swtch.com/vgo-tour
● 和訳：https://qiita.com/nekketsuuu/items/589bc29f00b507492a96

17. Go with Versions
■ GopherCon Singapore 2018でのRuss Coxの発表

18. Thank you!
twitter: @tenntenn
Qiita: tenntenn
connpass: tenntenn
18