Edited at
WACULDay 8

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

More than 1 year has passed since last update.


tl;dr

ちょうど dep (golang用のvendoringツール)を使っている中で、妙なバージョン運用をしているリポジトリに悩まされたので、

いまさらとは思いつつも「GitHubでバージョン管理するならこうだよね」ということをまとめてみました。


Semantics Versioning

バージョン番号自体の運用方法については、割と大きなスタンダードがすでにあって、Semantics Versioning(以下semver)がよく使われています。

意外と細かいところで悩まされることも多いので、一度文書には目を通しておいたほうがいいでしょう。英語が難しいという人には日本語の文書も公開されています


GitHubでの運用

GitHubでこのsemverで運用しようと思った場合、やりかたは色々あるとは思いますが、基本はTagsとブランチの運用になるでしょう。 

先の文書に示されたスタンダードと、いくつかsemver関連のツールを触ってみた感じ、次のような運用が良さそうです。


ブランチ



  • masterブランチは、最新の 安定した バージョン


    • バージョニングなんてしらん!というツールやユーザーのためには、masterは安定していることが大切




  • メジャーバージョンごとにブランチ(以下メジャーブランチとする)を用意する


    • 過去のメジャーバージョンにもメンテの可能性が当然ある

    • 破壊的変更を企んだ瞬間、新しいメジャーブランチを用意する


      • masterは安定していることが大切(大切なことなのでry)



    • 昔懐かしい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の9番目を 0.0.0-rc9 とするのは間違い。 0.0.0-rc.9 が正

    • 正直、よほど大規模なOSSでもない限り運用しないに越したことはなさそう


      • 詳しくは仕様文書の#11とか参照






まとめ

ただしいバージョンの運用は、OSSをやっていく上でとても大事なことです。

世の中のためにも、よりよいバージョン運用で、楽しいOSSライフを。