Project

General

Profile

リリース作業手順

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

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を眺め続ける。

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

原則として、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

である。

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

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

ruby trunk-src-dir/tool/merger.rb removetag 2.5.0-rc1

4. neonにログインして、パッケージを作る。

一般に「make distで」とか言われるわけだが、それを実行するためにはrubyのソースを用意してconfigureしとかないといけないわけなので、ここは安直にtrunkからtool/make-snapshottool/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で直してコミットしておこう。とはいうものの、そうした修正は困難であるため、作ろうとしているパッケージのバージョン近辺のmake-snapshotを使う方が無難かもしれない。また、make-snapshotはそれを実行するrubyインタプリタのバージョンに密接に影響していたり、またBASERUBY環境変数を参照したりもするので、必要なバージョンのrubyインタプリタを用意してそれを使って実行し、さらに、その際にはそのrubyインタプリタをBASERUBY環境変数で指定したりする必要があるかもしれない。あるいはPATHの先頭に入れるとか。なんにせよ、make-snapshotがエラーを吐いた時は、こういった諸事項を確認するとよい。

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

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

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

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

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

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

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

release.shは他のブランチメンテナから入手すること。

7. へこへことリリースアナウンスを書いてwww.ruby-lang.orgに掲載する。

とりあえず日英の2箇所を更新するのが自分の責任範囲だと思ってよい。最悪英語だけでもいいが。
よくわからんかったら前回のアナウンス文面を穴があくほど見つめるとよい。

アナウンス文中にはダウンロードURLやハッシュ値を書くことになる。
4.でコピペしておいた内容を転記するわけだが、パッケージのパスを有効なURLに書き換えるのを忘れないように。
なおURLは https://cache.ruby-lang.org/pub/ruby/1.9/ruby-1.9.3-pXXX.拡張子 になる(2.1以降は -pXXX は存在しない)。

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

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

一応、デプロイについて記しておくと、

  1. https://github.com/ruby/www.ruby-lang.org のmasterにマージされた時点で、Travis CIでテストビルドが行われる。
  2. Travis CIのテストビルドが成功すれば、今度はHerokuのstaging環境向けのビルドおよびデプロイが行われる。
  3. staging環境でチェックが完了したら、Herokuのpromoteボタンを押すと、ほぼ即座に本番環境に反映される。
  4. ただし、本番環境サイトのコンテンツはfastlyでキャッシュされているので、これだけではユーザーには更新内容が見えない。 よって、何らかの手段でキャッシュをパージしなければならない。一番簡単なのは、Slackの適切なチャンネルで @ruboty fastly purge all www と叫ぶ方法である。botさんがなんとかしてくれる。

8. アナウンス文面を適当に書いてruby-listとruby-talkに投げる

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

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を押す。

Promote は Slack で #ruby-lang-org を見つつ /h promote www-ruby-lang to prod でも良い。キャッシュパージは ruboty fastly purge all www でも良い。