3.6 betaX から 3.6RC1 に向けてのブランチ計画に関してメモが発掘できたので貼ってみる

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 週間前までは作らない

$ stat op3_release_branch_process.rst
16777217 11067796 -rw-r--r-- 1 co3k staff 0 3590 "Jun 27 13:11:29 2011" "Jun 27 13:11:29 2011" "Jun 27 13:11:29 2011" "Jun 27 13:11:29 2011" 4096 8 0 op3_release_branch_process.rst