Project

General

Profile

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にコミットしておこう。

ちなみに、チケット番号を入れ忘れた場合、コミットメッセージはもちろんもはや変えられないが、Redmine側は
リビジョンのページ からチケットを紐付けることが出来る。

2. じっとRubyCIとRubyInstaller CIを眺め続ける。

更新されるまで時間がかかるので気長に待つこと。

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

3. 機が熟したと思ったら、タグを打つ。

※ できごころでpreview/rcをalphaやbetaにしないように。Gem::Versionの比較順はdev<preview<rcという順序を前提にしているため、devを指定しているgemがalphaだと壊れる

タグの打ち方は、

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しておくこと(これは前回リリースの直後が望ましい)。

4. 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 部分は不要。
この時、できたパッケージ(4個)について、サイズとかSHA2とかが表示されるので、ちゃんとコピペして取っておくこと。

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

5. この時点で周りのruby開発者に声をかけてテストしてもらう。

RubySpecまで通っているからといって油断はできない(前例あり)。
特にRails使いに確認してもらうと安心度がぐっと上がる。

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

6. もう大丈夫かなーと思ったらリリースする。

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

リリースとは要するに公開ディレクトリにパッケージファイルを置くことである。
具体的には、パッケージのあるディレクトリに移動して、先ほど用意したrelease.shを実行すればよい。
release.shは、

  1. ~ftp/pub/ruby/1.9に今回のパッケージをコピーして、
  2. ftpのトップに今回のパッケージへのリンクを作成して、
  3. さらにruby-1.9-stable.拡張子というリンクも作る という仕事をしてくれる。

1.9部分は適宜他のバージョンに読み替えてそのまま通用する。

7. へこへことアナウンスメールを書いてruby-listとruby-talkに投げる。

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

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

8. アナウンス文の内容をちょっと加工して、www.ruby-lang.orgに掲載する。

とりあえず日英の2箇所を更新するのが自分の責任範囲だと思ってよい。
よくわからんかったら前回のアナウンス文面を穴があくほど見つめるとよい。
文面はmarkdownで書いて、https://github.com/ruby/www.ruby-lang.org をforkしてpull reqするのがおそらく正規の手順である。
また、ダウンロードページに直リンクがあるかもしれないので、そこも確認して必要なら直すこと(現在は基本的には自動的に更新されるようになっている模様)。
なお、dateメタフィールドに未来の日時を入れるとデプロイに失敗する。いろいろ言いたいことはあるが、ぐっとこらえて、pull reqがマージされるであろう時刻(=stagingに記事が掲載される時刻)より前の時刻を推定して記載しておくこと。
_data/download.yml 内にリリースしたパッケージの情報の記述があるので、それを更新するのも忘れないように。

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

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

10. これですべき作業は全てである。お疲れ様でした。

後は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. 新ブランチを作る（作らないとパッチレベルを変えられない）
  2. 事前に、version.hのRUBY_PATCHLEVELを0に変える。コミットを忘れずに。
  3. merger.rbでのタグ打ちの際は、「2.2.0」などという引数を付加する。この際、RUBY_PATCHLEVELが0以外だとエラーになる。
  4. make-snapshotでできたパッケージ名およびパッケージ内のディレクトリが「ruby-2.2.0」などになる。 また、ruby -vが自動的に「ruby 2.2.0p0」などになる。 「ruby 2.2.0dev」とかのままなら、たぶん(1)ができてない。
  5. .travis.ymlに新ブランチを追加する
  6. matzにtrunkバージョンアップの儀を催促する include/ruby/version.hも変えてもらう
  7. RedmineのBackport欄のデフォルト に新バージョンを足す
% svn cp -m "stable branch of Ruby 2.3" svn+ssh://svn@ci.ruby-lang.org/ruby/trunk svn+ssh://svn@ci.ruby-lang.org/ruby/branches/ruby_2_3
% cd ..
% svn co svn+ssh://svn@ci.ruby-lang.org/ruby/branches/ruby_2_3
% cd ruby_2_3
% vi version.h # #define RUBY_PATCHLEVEL 0
% svn ci
% merger.rb tag 2.3.0
% autoconf

% mkdir ~/obj/ruby_2_3
% ../../src/ruby_2_3/configure --disable-install-doc --enable-shared --without-tk --with-opt-dir=/usr/local --prefix=/home/naruse/local/ruby_2_3
% make Makefile;make Makefile&&make -j8 install-nodoc
% rm tmp/ruby-*;make dist RELNAME=2.3.0
% scp tmp/ruby-*.* ftp.ruby-lang.org:
% ssh ftp.ruby-lang.org
naruse@neon:~$ sudo -u ftp ./release.sh

% git tag v2_3_0 origin/tags/v2_3_0 && git push ruby v2_3_0

w.r-l.o の更新

参考までに

GitHubでPRをマージすると、HerokuのGitHub連携でstagingにdeployされる。
本番に反映するには、Herokuにログインしてw.r-l.oのPipelineを開き、"Promote to production"を押す。
Webを確認して更新されていなかったら、CDNのキャッシュが更新されていないので、Fastlyにログインして、上部からconfigure → Serviceからw.r-l.o → Purge → Purge Allを押す。