Skip to content

How To Release JA

Jump to bottom Edit New page
Takashi Kokubun edited this page May 30, 2024 · 14 revisions

リリース作業手順

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

1. 日々淡々とバックポートを行う。

バックポートの方法は

ruby ruby-master/tool/merger.rb --ticket=バックポートチケットの番号 リビジョン番号,リビジョン番号,...

である。チケットの番号、リビジョン番号は数字のみで。

バックポートチケットがないこともあるので、その場合は--ticket=は省略。

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

ruby ruby-master/tool/merger.rb revisionup

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

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

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

なお、セキュリティissueについては別途取り扱われているので、非公開ドキュメントに記載してある「対応手順」を確認すること

バックポートが必要なチケットの一覧は tool/redmine-backporter.rb で ls を実行すると確認できる。 このコマンドで show チケット番号 をした後 backport をすると merger.rb コマンドが出力でき、done でバックポートステータスを更新できる。

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

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

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

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

タグの打ち方は、

ruby ruby-master/tool/merger.rb tag

である。

previewやrcの場合は、

ruby ruby-master/tool/merger.rb tag 2.5.0-rc1

などと、明確に対象を引数として指定する必要がある。

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

ミスが発覚したなど、なんらかの理由でタグを消す場合は、以下のようにする。

ruby ruby-master/tool/merger.rb removetag 2.5.0-rc1

4. GitHub Actions でパッケージを作る。

以下のどれかの方法でスタートする。

a. https://github.com/ruby/actions/actions/workflows/draft-release.yml で「This workflow has a workflow_dispatch event trigger.」の横の「Run workflow」で「Packaging target version」にバージョン (タグ名vX_Y_ZではなくX.Y.Z) を指定して Run workflow する。

b. https://github.com/ruby/actions の tool/trigger-draft-release.sh をタグを引数にして実行する。

git pull 
./tool/trigger-draft-release.sh v2_5_0_rc1

c. webhook 経由で実行する。(hub コマンドを使っていて ~/.config/hub から読めるなら TOKEN は省略可能)

TOKEN=githubのoauthのrepo権限のあるtoken ./tool/trigger-snapshot.sh refs/tags/v2_5_0_rc1

Slack に通知が届いたら Amazon S3 s3://ftp.r-l.o/ のpub/tmp/ にパッケージがアップロードされているのを確認する。

何か問題があれば https://github.com/ruby/actions/actions?workflow=Make+draft+release+package からログを見て修正する。

5. できたパッケージをテストする

RubyCIで緑だから、といって油断はできないので、ちゃんとパッケージ自体をテストする必要がある。 また、なるべく多様な環境で確認することが望ましい。 特にRails使いに確認してもらうと安心度がぐっと上がる。

テストに際しては、configure時に --with-baseruby=noruby などとして、rubyがない環境でビルドできることも確認すること

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

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

リリースとは要するに公開ディレクトリにパッケージファイルを置くことである。

Amazon S3の s3://ftp.r-l.o の pub/ruby/X.X/ 以下にパッケージファイルをアップロードすると s3 並びに CDN 経由で公開される。

tool/release.sh を使ってもよい。

アップロード直後、何故かFastlyのネガティブキャッシュが効いていてダウンロードできないことが多いので、実際のURLでダウンロードできなかったらSlack上で以下のようにキャッシュをパージする。

@ruboty fastly purge https://cache.ruby-lang.org/pub/ruby/3.3/ruby-3.3.2.tar.gz
@ruboty fastly purge https://cache.ruby-lang.org/pub/ruby/3.3/ruby-3.3.2.tar.xz
@ruboty fastly purge https://cache.ruby-lang.org/pub/ruby/3.3/ruby-3.3.2.zip

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

7.1 リリースアナウンスを書く

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

アナウンス文中にはダウンロードURLやハッシュ値を書くことになる。 4.でコピペしておいた内容を転記するわけだが、パッケージのパスを有効なURLに書き換えるのを忘れないように。 なおURLは https://cache.ruby-lang.org/pub/ruby/2.4/ruby-2.4.3.拡張子 になる。 このとき、tool/format-releaseを用いてパッチを作成し、 git apply release.patch で反映してもよい。

文面はmarkdownで書いて、https://github.com/ruby/www.ruby-lang.org をforkしてpull reqするのが正規の手順である。 なお、dateメタフィールドに未来の日時を入れると jekyll の都合でデプロイに失敗する。いろいろ言いたいことはあるが、ぐっとこらえて、pull reqがマージされるであろう時刻(=stagingに記事が掲載される時刻)より前の時刻を推定して記載しておくこと。 _data/releases.yml や _data/download.yml 内にリリースしたパッケージの情報の記述があるので、それを更新するのも忘れないように。これを忘れるとダウンロードページが更新されない。 (rake lint などとの都合から、事実上日本時間午前9時以降でないとリリース出来ない)

changelog については tool/gen-github-release.rb というものを用意している。環境変数 GITHUB_TOKEN に ruby/ruby のリポジトリの Contents scope に read/write 権限を持つ credential を設定して以下のコマンドを実行する。

3.2.1 リリースの時の実行例:

$ ruby tool/gen-github-release.rb v3_2_0 v3_2_1

で出力を確認して

$ ruby tool/gen-github-release.rb v3_2_0 v3_2_1 --no-dry-run

で https://github.com/ruby/ruby/releases/tag/v3_2_1 が作成されるので、このリンクをリリースアナウンスに含めるとユーザーフレンドリーである。(うまく動かない時は @hsbt を呼ぶか、この作業はスキップする)

7.2 www.ruby-lang.orgに掲載する

staging環境へのdeployは、masterにマージすると自動で反映されるのだが、git push staging HEAD:master などとすればよい。

無事にmasterにマージされたら(または自分でマージしたら)、GitHub Actionsによって GitHub Pages にデプロイされる。

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

9. バージョン番号の teeny を上げておく (optional)

rubyspec はバージョン番号でテストを分岐することがよくあるので、新たにバックポートをはじめる前に teeny を上げておこう。 仕様の変化するような変更はしないというのが基本方針だが rubyspec は仕様というより不具合もそのまま再現したテストが良く書かれる。

ruby ruby-master/tool/merger.rb teenyup

これをやるかどうかは人による。やらなくてもいい。

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

後はTwitterでリリースした旨をつぶやいてRT数を稼ごう :)

リリース後関連作業

リリース後のリリースに関連する作業のリストです。 手を動かす人はリリースした人とは関係ないものも含まれます。

初回リリース(X.Y.0)の時

EOL

初回リリース(X.Y.0)の場合の特記事項、追加作業について

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でのタグ打ちの際は、「3.3.0」などという引数を付加する。この際、RUBY_PATCHLEVELが0以外だとエラーになる。
  4. この後は通常のリリース手順と同じ
  5. [GitHubのbranch protection ruleの追加](https://github.com/ruby/ruby/settings/branches
  6. matzにmasterバージョンアップの儀を催促する include/ruby/version.hも変えてもらう
  7. RedmineのBackport欄のデフォルト に新バージョンを足す
  8. git.r-l.o<->GitHub双方向同期ブランチへの追加: https://github.com/ruby/ruby-commit-hook/commit/9f345412d4836e5e9c7998e89535908fc571d0ca 
git br ruby_3_3
git worktree add ../ruby_3_3
cd ../ruby_3_3
vim version.h
git push git.ruby-lang.org HEAD
# GitHubにbranch protectionを追加 https://github.com/ruby/ruby/settings/branches
merger tag 3.3.0
(cd ~/work/ruby-actions;git pull --progress --rebase&&tool/trigger-draft-release.sh v3_3_0)
cd ~/work/[www.ruby-lang.org](http://www.ruby-lang.org/)
pull --rebase
~/work/ruby/tool/format-release . 3.3.0 ~/work/ruby|git apply
~/bin/ruby-release
tool/release.sh 3.3.0

# 不幸にもブランチを作り直す場合
cd ~/work/ruby
git pull --rebase
git worktree remove ruby_3_3
git br -D ruby_3_3
git br ruby_3_3
git worktree add ../ruby_3_3
cd ../ruby_3_3
vim version.h
merger removetag 3.3.0 ; merger tag 3.3.0
git push -f git.ruby-lang.org ruby_3_3

Policies

Development

For developers

For committers

Technical Information

Documentation

Miscellaneous

Clone this wiki locally