History

Main »

リリース作業手順

メンテナンスブランチの場合

  1. 日々淡々とバックポートを行う。 ちなみにバックポートの方法は ruby trunk-src-dir/tool/merger.rb --ticket=バックポートチケットの番号 リビジョン番号,リビジョン番号,... である。チケットの番号、リビジョン番号は数字のみで。 バックポートチケットがないこともあるので、その場合は--ticket=は省略。

バックポート元がない修正の場合は手動でコミットすることになるが、コミットの前に

ruby trunk-src-dir/tool/merger.rb revisionup

を忘れずに。適切にversion.hを更新してくれる。

なお、ここで使うrubyおよびmerger.rbはtrunk最新が望ましい。
他のブランチのmerger.rbはバグったままであることが多い(いちいちバックポートしない)ので、これが安心確実。
何か不都合があったら、ちゃんと直してtrunkにコミットしておこう。

  1. じっとRubyCIとRubyInstaller CIを眺め続ける。更新されるまで時間がかかるので気長に待つこと。
    原則として、RubySpecを含めて、問題がいっさいない場合しかリリースしない。EかFがあったら(1)に戻ろう。
    ただし、プラットフォーム特有の何かとか、タイミングによって起きたりするエラーは往々にしてあるので、その辺は以前のリリース時の結果も踏まえて臨機応変に。
    RubySpecのバグとかもたまにあるので、見つけたら報告して直してもらう。

  2. 機が熟したと思ったら、タグを打つ。
    タグの打ち方は、

    ruby trunk-src-dir/tool/merger.rb tag

    である。

ちなみに、なんらかの理由でタグを消す場合は、以下のようにする。

svn rm -m "remove tag v1_9_3_XXX" svn+ssh://svn@ci.ruby-lang.org/ruby/tags/v1_9_3_XXX

なお、2.1以降はタグのルールが変更されている。具体的には、パッチレベルを意味する _XXX 部分が不要になる。
事前にversion.hを更新し、RUBY_PATCHLEVELは手でいじらずに、RUBY_VERSION内のteenyを上げてcommitしておくこと(これは前回リリースの直後が望ましい)。

  1. neonにログインして、パッケージを作る。 一般に「make distで」とか言われるわけだが、それを実行するためにはrubyのソースを用意してconfigureしとかないといけないわけなので、ここは安直にtrunkからtool/make-snapshot、tool/downloader.rb(旧 config_files.rb)、tool/release.shの3つのファイルを取ってきて、 ruby make-snapshot 適当なディレクトリ名 1.9.3-pXXX を実行した方がよい。ここでも、2.1以降の場合は -pXXX 部分は不要。 この時、できたパッケージ(3個)について、サイズとかMD5とかが表示されるので、ちゃんとコピペして取っておくこと。

make-snapshotがエラーを吐いたら(たまにtrunk依存が埋め込まれていたりするので油断ならない)、ちゃっちゃとtrunkで直してコミットしておこう。

  1. この時点で周りのruby開発者に声をかけてテストしてもらうのが無難である。 RubySpecまで通っているからといって油断はできない(前例あり)。 特にRails使いに確認してもらうと安心度がぐっと上がる。

テスト用配布にはneonの~ftp/pub/tmp/が使える。

  1. もう大丈夫かなーと思ったら、((5)でテスト配布をしていたらそれをちゃんと削除して)リリースを行うことになる。なお、マズった、と思ったら、(3)で打ったタグをsvn rmして(1)に戻る。

リリースとは要するに公開ディレクトリにパッケージファイルを置くことである。
具体的には、パッケージのあるディレクトリに移動して、先ほど用意したrelease.shを実行すればよい。
release.shは、
1. ~ftp/pub/ruby/1.9に今回のパッケージをコピーして、
2. ftpのトップに今回のパッケージへのリンクを作成して、
3. さらにruby-1.9-stable.拡張子というリンクも作る
という仕事をしてくれる。
1.9部分は適宜他のバージョンに読み替えてそのまま通用する。

  1. へこへことアナウンスメールを書いてruby-listとruby-talkに投げる。 単に英語でだけ書いてruby-listとruby-talkに同時に投げるとか、日英併記してruby-listとruby-talkに同時に投げるとか、で特に誰からも苦情は来ないとは思うが、日本語はruby-listに、英語はruby-talkに、と丁寧に投げ分けるとちょっと親切かもしれない。あと、ここで英語でだけ書いたとしても、どうせ後で日本語でのアナウンス文は必要になる。 メールを投げるときにはPGP鍵で署名しておくといいかもしれない。

アナウンス文を書くとき、(4)でコピペしておいた内容を転記するわけだが、パッケージのパスを有効なURLに書き換えるのを忘れると赤っ恥をかくことになるので注意しよう(前例あり)。
なおURLは http://cache.ruby-lang.org/pub/ruby/1.9/ruby-1.9.3-pXXX.拡張子 になる(2.1以降は -pXXX は存在しない)。

  1. アナウンス文の内容をちょっと加工して、www.ruby-lang.orgに掲載する。 とりあえず日英の2箇所を更新するのが自分の責任範囲だと思ってよい。 よくわからんかったら前回のアナウンス文面を穴があくほど見つめるとよい。 2013年春からwww.ruby-lang.orgの中のシステムが変更されている。 文面はmarkdownで書いて、https://github.com/ruby/www.ruby-lang.org をforkしてpull reqするのがおそらく正規の手順である。 また、ダウンロードページに直リンクがあるかもしれないので、そこも確認して必要なら直すこと(現在は基本的には自動的に更新されるようになっている模様)。

正直いろいろ手順的にどうしようもない(特にデプロイが……)ので、hsbtさんあたりに泣きつくのが吉。

  1. もしあなたが業務として保守作業を行っているなら、報告書への記載を忘れずに :)

  2. これですべき作業は全てである。お疲れ様でした。
    後はTwitterでリリースした旨をつぶやいてRT数を稼ごう。

初回リリースの場合

preview、rcについて

  1. 基本的な手順はおおむね上記と同じ。ただ、タグ名が変わるので、そこだけ注意。 具体的には、merger.rbでのタグ打ちの際に、「2.2.0-preview1」などという引数を付加する。 この際、RUBY_PATCHLEVELが-1以外だとエラーになる。
  2. make-snapshotでできたパッケージ名およびパッケージ内のディレクトリが「ruby-2.2.0-preview1」などになる。 また、ruby -vが自動的に「ruby 2.2.0preview1」などになる。 なってなかったらタグ名がおかしいか、make-snapshotがバグってるかどちらか。

初回の正式リリースについて

  1. 事前に、version.hからRUBY_BRANCH_NAMEの行を削除し、RUBY_PATCHLEVELを-1から0に変える。コミットを忘れずに。
  2. merger.rbでのタグ打ちの際は、「2.2.0」などという引数を付加する。この際、RUBY_PATCHLEVELが0以外だとエラーになる。
  3. make-snapshotでできたパッケージ名およびパッケージ内のディレクトリが「ruby-2.2.0」などになる。 また、ruby -vが自動的に「ruby 2.2.0p0」などになる。 「ruby 2.2.0dev」とかのままなら、たぶん(1)ができてない。