Gauche:リリース工程

とりあえず、0.8.x近辺でのカレントプラクティスを記録しておく。

リリースのタイミング

最近は2ヶ月おきが目安。どうしても直しておきたいバグや 入れたい機能があって、それが遅れるとリリースも遅れる。 一方、2ヶ月に満たなくても忙しくなりそうなことがわかっている 場合は早めに出してしまうこともある。

「これとこれとこれが終わったらリリースしよう」という目算を だいたい2週間前くらいから立て始める。もちろん目算が狂うこともよくある。 そのくらいの時期を目安に、MLやGauche:Bugsを眺めて、 対応し忘れているものが無いかも探す。

入れたい機能、直したいバグに対する作業が一通り済んだら、リリース作業に入る。 通常、2〜3日連続した、極端に忙しくない期間が必要。

リリース作業

前提：

• tarballはCVS版からなら ./DIST tgz で作れる。
• テストの基本は、 ./configure --prefix=<testdir>, make, make check, make install, make install-check。

工程：

1. ./DIST tgzでtarball作成
2. テスト
   • 各種アーキテクチャでのテスト: tarballを転送して、configureからmake install-check まで流す。転送先にad hocなスクリプトが作ってある。
     • 手元のマシン (Linux/x86, Windows/Cygwin)
     • sourceforge.net, sourceforge.jpのコンパイルファームで使えるマシン
     • HP test driveのHP-UXマシン
   • エンコーディングの違いによるテスト：ローカルで ./DIST testcode とすると、 4種類のエンコーディングオプションそれぞれでテストを流す。
   • 拡張ライブラリのテスト：ローカルのテストディレクトリにinstallした 状態で、いくつかのGaucheの拡張ライブラリをビルド、テスト、インストール。
   • rpmの作成テスト。./DIST rpm 等でrpmを作って、ローカルに入れてみる。
3. fix. テストで問題が出たら直す。修正をcommitしたら1.に戻る。
4. 上のサイクルを流している間に、webpageの方のリリースノートなど作成。
5. 一切の修正無しでテストが通るようになったらconfigure.acのバージョンを 正式バージョンにして、ChangeLogにリリースを記録。
6. リリース用tarball、src.rpm作成。
7. sf.netにアップロード、リリース。freshmeat.netの方もリリースを報告。 gaucheのwebpageもアップロード。
8. MLに流す。

時間を取るのは何といってもテストサイクルで、 ここで出た問題は個別に対応しなければならないうえ、 修正を入れたら再びテストサイクルを繰り返さなくてはならない (普通、いくつか並行して修正するけど)。 テスト自体は自動化、分散化が可能だと思うので、再テストの 同期などがうまくとれるようにすればツール化は可能だろう。