Skip to content
Kazuhiro NISHIYAMA edited this page Apr 2, 2025 · 34 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.rbls を実行すると確認できる。 このコマンドで 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 3.4.0-rc1

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

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

ミスが発覚したなど、なんらかの理由でタグを消す場合

以下のようにする。

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

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

ruby/ruby にタグを打った時点で https://github.com/ruby/ruby/blob/master/.github/workflows/publish.yml が trigger され、ruby/actions レポジトリに存在する https://github.com/ruby/actions/actions/workflows/draft-release.yml が起動する。

もし、何かしらの事象が発生し起動しない場合

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

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/actionstool/trigger-draft-release.sh をタグを引数にして実行する。

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

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

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

Slack に通知が届いたら Amazon S3 s3://ftp.r-l.o/pub/tmp/ にパッケージがアップロードされているのを確認する。(例: https://ftp.ruby-lang.org/pub/tmp/ruby-3.3.5-draft.tar.gz)

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

draft-release workflow によるテストが全て完了した場合 https://github.com/ruby/www.ruby-lang.org/pull/3342 のように 7. で必要となるリリースアナウンスの雛形が作成される。

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

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

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

wget https://ftp.ruby-lang.org/pub/tmp/ruby-3.3.5-draft.tar.gz

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

テスト配布をしていたならばそれをちゃんと削除して、その上でリリースを行うことになる。 なお、マズった、と思ったら、3.で打ったタグを削除(3.を参照)して1.に戻る。その際、 https://github.com/ruby/www.ruby-lang.org/ に自動作成された pull request は閉じておくことが望ましい。

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

https://github.com/ruby/ruby/actions/workflows/release.yml の workflow_dispatch をリリース対象の Ruby のバージョンを入力して実行する。

このワークフローによって実行される作業の詳細
  • Amazon S3の s3://ftp.r-l.o の tmp 配下にある draft パッケージファイルが pub/ruby/X.X/ に移動され、CDN 経由で公開される。
  • もし実行されない場合は tool/release.sh を使ってもよい。AWSのcredentialは普通は自分で作れないようになっているので、admin (e.g. @hsbt) に連絡してIAM userの作成とそのcredentialの共有をしてもらい、aws configure --profile ruby しておく。
tool/release.sh 3.0.0
  • Fastlyのネガティブキャッシュのパージが実行される。
    • 実行されない場合は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
  • changelog として tool/gen-github-release.rb が実行され、GitHub の ruby/ruby の Releases に作成される
    • うまく動かない場合は環境変数 GITHUB_TOKENruby/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 # GitHub に作成

最後の4つについては、実行されない場合にリリース担当が再実行する必要はないので、担当である @hsbt に連絡しておく。

最新のstableリリースの場合は、作られたGitHub releaseを編集してSet as the latest releaseにチェックをいれる。

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

前のステップで実行したワークフローが https://github.com/ruby/www.ruby-lang.org/pulls に Pull Request を作る。

手動で作成する場合

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

gem install diffy
tool/format-release ../www.ruby-lang.org 3.3.6 .

GitHub Actions によって、雛形が pull request としてすでに作成されているので、これを更新する。

GitHub上のエディタ等何らかの方法でauthorを修正し、必要ならリリース文言の更新を行ない、以下の通りに _data/downloads.yml_data/releases.yml の更新した後マージする。よくわからんかったら前回のアナウンス文面を穴があくほど見つめるとよい。masterにマージすると、GitHub Actionsによって GitHub Pages にデプロイされる。

_data の更新方法

_data/releases.yml_data/download.yml 内にリリースしたパッケージの情報の記述があるので、それを更新するのも忘れないように (2024年11月現在、ワークフローで自動化されていない)。これを忘れるとダウンロードページが更新されない。ruby/rubyで gem install diffy && tool/format-release ../www.ruby-lang.org 3.3.6 . で生成する。

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

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

ruby ruby-master/tool/merger.rb teenyup

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

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

後はXでリリースした旨をつぶやいて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
Clone this wiki locally