co3k/gist:4317540

## gistfile1.rst

      
    Raw
  

              gistfile1.rst
            
          
    OpenPNE3 release branching model in stable-3.6.x

図解

3.6.0 に向けたリリースブランチモデルは以下の図に示すとおり:
N---D'--F'--O [release-3.6beta12]

/


L---B'--C'--E'--M [release-3.6beta11]


/


A---B---C---D---E---F---G---H---I---J---K [stable-3.6.x]


OpenPNE-3.6RC1


ダッシュ付きアルファベットは cherry-pick を表す
"K" コミットまでの stable-3.6.x のバージョン番号は "OpenPNE-3.6RC1-dev" である
"G", "H", "I", "J", "K" は stable-3.6.x (3.6RC1-dev) にのみ存在するコミットである

どうしてこのモデルにするか

いままでの問題点


現在の stable-3.6.x ブランチにより開発、リリースをすすめる方針は破綻している


stable-3.6.x ブランチをリリース計画に合わせて育てられていない


ブランチやチケットの管理ができていない状態のまま、ブランチだけが成長してしまった

つまり管理する側のマンパワーに依存するモデルだった


その場合、テストやレビューが終わっていないコミットは一時的にリリースから外すのが筋だが、外す対象となるコミットの数が明らかに多すぎる


そもそも cherry-pick でコミットを適宜持ってくる方式が、 Subversion 時代のブランチ管理モデルから脱却しきれておらず、無理のあるものだった


しかし現在動いているモデルを 3.6 開発期間中に大きく変えることはできない

このモデルによる問題点の解決


そこで、 stable-3.6.x ブランチから各ベータ版リリースをおこなうのを諦め、各リリース毎にリリースブランチを作成していく方法により対処することにした
リリースブランチは、最新のタグが指し示すコミットから派生したブランチとなる
リリースブランチに直接変更をコミットしていくということはおこなわず、 stable-3.6.x からリリース対象となるコミットをリリースブランチに cherry-pick していくことによりブランチをリリースまで成長させていく
リリースブランチを採用したモデルは、最終ベータリリースまで継続する。最終ベータまでにはそれまでに想定していた修正はすべてリリースされているはずであり、従って、 stable-3.6.x (RC1-dev) と最終ベータのリリースブランチはバージョン番号を除いて同じソースコードになっているはずである。したがって、 RC1 の開発以降はリリースブランチを採用したモデルを維持する必要はない

本モデルを運営する際のルール


チケット単体でのコードレビューは stable-3.6.x に紐づいたコミットについてのみおこなう
cherry-pick は元のコミットが追跡できるように -w オプションをつけておこなう
動作テストはリリースブランチを利用してのみおこなう
リリースブランチはリリース 2 週間前までは作らない