GitHubでSemantic Versioning（セマンティックバージョニング）を運用する

この記事は拙著のQiita記事を移行してきたものです

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とか参照

まとめ

ただしいバージョンの運用は、OSSをやっていく上でとても大事なことです。
世の中のためにも、よりよいバージョン運用で、楽しいOSSライフを。