Zenn
🥸

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

2022/03/13に公開
GitHub
#
semver
#
Semantic Versioning
tech

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ライフを。

Discussion