成瀬です。

Ruby1.8.2 に続き、Ruby1.8.3 のリリースも当初予定の4月から遅れに遅れ、
外的な要因も相成って、結局ごたごたしてしまいました。
これの反省を生かすため、[ruby-dev:25635] を参考にしつつ、
「凍結」の概念を取り入れた 1.8.4 のリリースサイクル案を考えました。


第0週[10/16]: リリースサイクルの始まり
         日程を決める
         各種MLにその旨アナウンス
第1週[10/23]: リリースの枝の作成と機能の凍結
         ruby_1_8_4 ブランチの作成:
           このブランチでは機能追加を禁止

         各プラットフォームごとの動作検証をする人を募集→決定
         最終preview版を作る人募集→決定
         ドキュメント書く人を募集→作成
            1.8.3からの差分(日・英)
         リリースアナウンス告知担当者募集→決定
         各メディア(？ /.Jとか？)向けプレスリリース担当者募集→決定
第2週[10/30]:
         ruby_1_8_4 ブランチでのバグ修正
第3週[11/06]: preview1 リリース
         致命的でないバグの修正を凍結
第4週[11/13]:
         preview1 の動作検証
第5週[11/20]: preview2 リリース
         リリースとアナウンス
         リリースエンジニアの許可ない変更は致命的なものを除いて禁止
第6週[11/27]:
         preview2 の動作検証
第7週[12/04]: preview3 リリース
         リリースエンジニアの許可ない変更は全て禁止
第8週[12/11]: 正式版リリース
         アナウンスまでにドキュメントを準備する
第9週[12/24]: アナウンス
         各方面にアナウンス

なお、この案では、
* ruby_1_8_4 ブランチをきってしまう事で、
  あらゆる変更がそもそも入りづらくする
* 凍結ポリシーに反した変更が入ってしまった場合は、
  CVSのログを見張ってくださっている方が指摘してくださる事を期待
* 「リリースエンジニアの許可ない変更」というところは
  Rubyの場合ではMLに投げて異議のなかった、でもいいかも



また、[ruby-dev:27259] で指摘されているような問題については、
OpenBSD's Flavors に書かれているものが近いように感じます。
http://openbsd.org/faq/faq5.html#Flavors

これを一桁ずらせば、そのまま ruby のモデルになるかと。
つまり、以下のような感じです。
       ,------o-----------o----X                    1.8.3 Stable
       |      .           .
       |      .    ,------o---------o----X          1.8.4 Stable
       |      .    |      .         .
       |      .    |      .    ,----o----------o--> 1.8.5 Stable
       |      .    |      .    |    .          .
       |      .    |      .    |    .    ,-----o--> 1.8.6 Stable
       |      .    |      .    |    .    |     .
       |      .    |      .    |    .    |     .
 -->1.8.3Rel--->1.8.4Rel--->1.8.5Rel-->1.8.6Rel---> ruby_1_8

なおこの場合では、
それぞれのパッチリリースは1.8.3.1のように4桁になる事が予想されますが、
これに伴う問題はあるのでしょうか？

-- 
NARUSE, Yui  <naruse / airemix.com>
DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA