tl;dr
ちょうど dep (golang用のvendoringツール）を使っている中で、妙なバージョン運用をしているリポジトリに悩まされたので、
いまさらとは思いつつも「GitHubでバージョン管理するならこうだよね」ということをまとめてみました。
Semantics Versioning
バージョン番号自体の運用方法については、割と大きなスタンダードがすでにあって、Semantics Versioning(以下semver)がよく使われています。
意外と細かいところで悩まされることも多いので、一度文書には目を通しておいたほうがいいでしょう。英語が難しいという人には日本語の文書も公開されています。
GitHubでの運用
GitHubでこのsemverで運用しようと思った場合、やりかたは色々あるとは思いますが、基本はTagsとブランチの運用になるでしょう。
先の文書に示されたスタンダードと、いくつかsemver関連のツールを触ってみた感じ、次のような運用が良さそうです。
ブランチ
-
masterブランチは、最新の 安定した バージョン
- バージョニングなんてしらん！というツールやユーザーのためには、masterは安定していることが大切
-
メジャーバージョンごとにブランチ（以下メジャーブランチとする）を用意する
- 過去のメジャーバージョンにもメンテの可能性が当然ある
- 破壊的変更を企んだ瞬間、新しいメジャーブランチを用意する
- masterは安定していることが大切（大切なことなのでｒｙ）
- 昔懐かしいjQueryとか、1.xと2.xの共存期間が長かったですね。 ~python2?え？~
-
メジャーブランチの名は
v1.xの様に、vメジャーバージョン番号+.x(固定文字列) とする- 一部のツールは、タグもブランチも一絡げに捉えようとする
- "ブランチ" はあくまで開発が行われる場所なので、単一のバージョンを指している "タグ" とは命名規則を分けたほうがいい
- semverに詳しくない人にとっては、
v1ブランチとv1.0.0タグの両方がある世界は混乱するだけ-
.xがどの程度効くかは不明だけど
-
タグ
-
作業ブランチでは打たず、メジャーブランチのコミットに対して打つ
- squash mergeなんかされて、対象のコミットがない、みたいな話もちょっと悲しい
-
命名はsemverの仕様に則る（大事）
- 例：1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0
-
罠としては、vを先頭につけるとオーダーひっくり返ったりする場合があるかも？
- v0, v1, v10, v2, ...v9 とかなっちゃったり
- semverは先頭のvを定義していない。先頭に付くvをどう処理するかは処理系次第（そんなー）
-
プレリリースバージョンは極めて分かりづらいので注意
- RCの９番目を
0.0.0-rc9とするのは間違い。0.0.0-rc.9が正 - 正直、よほど大規模なOSSでもない限り運用しないに越したことはなさそう
- 詳しくは仕様文書の#11とか参照
- RCの９番目を
まとめ
ただしいバージョンの運用は、OSSをやっていく上でとても大事なことです。
世の中のためにも、よりよいバージョン運用で、楽しいOSSライフを。