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。
工程:
- ./DIST tgzでtarball作成
- テスト
- 各種アーキテクチャでのテスト: 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を作って、ローカルに入れてみる。
- 各種アーキテクチャでのテスト: tarballを転送して、configureからmake install-check
まで流す。転送先にad hocなスクリプトが作ってある。
- fix. テストで問題が出たら直す。修正をcommitしたら1.に戻る。
- 上のサイクルを流している間に、webpageの方のリリースノートなど作成。
- 一切の修正無しでテストが通るようになったらconfigure.acのバージョンを 正式バージョンにして、ChangeLogにリリースを記録。
- リリース用tarball、src.rpm作成。
- sf.netにアップロード、リリース。freshmeat.netの方もリリースを報告。 gaucheのwebpageもアップロード。
- MLに流す。
時間を取るのは何といってもテストサイクルで、 ここで出た問題は個別に対応しなければならないうえ、 修正を入れたら再びテストサイクルを繰り返さなくてはならない (普通、いくつか並行して修正するけど)。 テスト自体は自動化、分散化が可能だと思うので、再テストの 同期などがうまくとれるようにすればツール化は可能だろう。