Go に限らず、公開しているプロジェクトのバージョニングは必要だけれど面倒なタスクのひとつで、プロジェクトのメンテナンスを続けていくつもりがあるのなら、ほぼ必ず通らなければならない道でしょう。ここで話題にしているのは Git などによるソースコードのバージョン管理ではなく、たとえばバージョン 3.1.4 といった、リリースされるソフトウェアの公開バージョンをどう運用するか、という話です。
バイナリとして配布する前提のプロジェクトであればソース中で var version string と宣言した変数に、ビルド時に -ldflags '-X main.Version 3.1.4' などとしてバージョンを設定するという方法もありますが、go get による配布ができるのなら、提供側としては楽ができます。たとえば gore は開発者向けということでバイナリの配布をしていませんが、リリース作業がないとなると意識してバージョンを切るタイミングがないので、ここを自動化したいものです。
幸い Go はソースコードの操作がとても簡単に行えるので、version 変数に代入されている文字列リテラルを書き換える……というようなことの実現もたいした苦労ではありません。
gobump
そこで作ったのが gobump。
go get github.com/motemen/gobump/cmd/gobump
Go プロジェクトのワークツリーで、以下のようにして使います:
gobump minor -w
バージョニングが Semantic Versioning に従っている前提で、ソースコード中のバージョン的な（/^version$/i）変数や定数に与えられている値を進めます。第一引数には "major"、"minor"、"patch" を与えることができて、それぞれバージョン番号の対応する箇所をインクリメントさせます。たとえば上の例だと、
package main const version = "1.2.3"
みたいなコードが
package main const version = "1.3.0"
に書き換えられる。
-w は gofmt や goimports など標準のツールにおなじみのオプションで、バージョンアップ後のコードを標準出力に印字する代わりに、対象のファイルの内容を書き換えます。 この際 -v オプションを与えると、書き換えられた名前と値が JSON で出力されるので、スクリプトからの利用に便利です。
% gobump minor -w -v
{"version":"1.3.0"}
これを利用した自動化については後ほど紹介します。2015-08-13: 書きました。
