Ruby の安定版リリースとメンテナンス方針のご紹介

Rubyコミッタのしごと

こんにちは、モンスターハンター・ワイルズのアップデートの合間にアサシンクリード・シャドウズをプレイして近畿地方を走り回るついでに原神をプレイしている hsbtです。ゼノブレイドクロスも進めたいのですが物理的に時間が足りません...。

さて、今回は Ruby の安定版リリースを 2025 年にどのように対応しているのか、についてご紹介します。

Rubyのバージョニングナンバーの意味

まず Ruby のバージョニングポリシーについてご紹介します。Ruby は Ruby 2.1 より以前は 1.9.3-p551 や 2.0.0-p648 というように patchlevel と呼ばれる修正したコミットの数をバージョンナンバーに加えていましたが、Ruby 2.1.0のリリースから、私の提案でセマンティックバージョニングタイプのポリシーへと移行しました。これは以下に示すような形式です。

MAJOR.MINOR.TEENY
  • MAJOR：インパクトの大きい互換性のない変更があり、MINORレベルではリリースできない場合に増加する。特に Matz が気持ちを込めてリリースする特別なイベント用に予約されている。
  • MINOR：毎年クリスマスに増加し、新しい安定版バージョンとなる。API互換性がない変更も含まれることがある。
  • TEENY：API互換性を維持したセキュリティ修正やバグ修正、2-3ヶ月ごとにリリース、2.1.10 のように 10以上の値になることもある。

MAJOR が上がった最近の例としては Ruby 3x3、 並列/並行機構、Soft Typing が揃ったら Ruby 3 とするという例があります。余談ですが最近見かけた Pride Versioning 🏳️‍🌈 0.2.0 は Ruby のバージョニングポリシーとほぼ同じと感じました。

ブランチ管理体制

Ruby開発チームでは以下のブランチで開発を行っています。

  • master: 開発版バージョン、2025/4 現在の予定リリースバージョンは 3.5.0
  • ruby_{MAJOR}_{MINOR}: 安定版バージョン、新しい安定版リリースが行われたあと3-4ヶ月は4バージョンを用い、その後の8-9ヶ月は3バージョンとなる。
    • 2025/4現在は ruby_3_4, ruby_3_3, ruby_3_2 の3バージョン、3月までは ruby_3_1 も開発していた。

Ruby 開発チームでは LTS バージョン、というものはなく常に新しいバージョンの開発とリリースを行い、その後数年かけて EOL としていく開発モデルです。具体的には安定バージョンは3 または4バージョンあり、そのうちリリースがより新しい2または3つのバージョンは機能修正も含むノーマルメンテナンスバージョン、残りの1つはセキュリティメンテナンスバージョンとなります。

時期によって数が変わり少しややこしくなるので具体的なバージョンを例示すると以下の通りです。

2024/12/25-2025/3-4 の期間

  • 3.4.x、3.3.x、3.2.x: ノーマルメンテナンス
  • 3.1.x: セキュリティメンテナンス

2025/3-4 以降

  • 3.4.x、3.3.x: ノーマルメンテナンス
  • 3.2.x: セキュリティメンテナンス

以降、2025/12/25 に予定通り Ruby 3.5.0 がリリースされた場合は 3.5.x がノーマルメンテナンスバージョンの対象として加えられ、2026 年の3月ごろに3.2のセキュリティメンテナンスを終了し、3.3 を新たにセキュリティメンテナンスバージョンへと変更します。

ブランチメンテナとノーマルメンテナンスポリシーの紹介

ブランチメンテナは現在は nurse、 k0kubun、nagachika、hsbt の4人で行っています。nurse さんは開発版バージョンを担当し、毎年 12/25 に新しい安定バージョンをリリースしています。残りの3名は安定版バージョンのメンテナです。

昨年に提案された Misc #20432: Proposal for workflow changes related to teeny releases を受けて、k0kubun さんが最新のノーマルメンテナンスバージョン、私がセキュリティメンテナンスバージョンのブランチメンテナに就任しました。nagachika さんは引き続き、間のバージョンのブランチメンテナを担当していきます。

以前と変わってきた点としてはk0kubun さんは2-3ヶ月おきに新しいバージョンをリリースしている点です。そのために私は、アナウンスの雛形作成や CDN への公開とネガティブキャッシュのパージなど今までは手順書 + 手動で行ってきた様々な作業を GitHub の機能をフル活用して全部自動で実行されるようにしました。従来の仕組みでも git tag を打つだけで Ruby のパッケージが作成され、テストまでは実行されていましたが、より自動化を進めることでブランチメンテナがリリースを行うときの障壁を下げられたのではないかと思います。

Ruby 3.3 では 3.3.1 のリリースの後にブランチメンテナを交代最近は Shopify の Ruby ecosystem チームが master で修正された問題のトリアージとパッチや pull request の作成を積極的に行い、最新の安定バージョンである Ruby 3.4 に k0kubun さんがバックポートを行うという流れができつつあります。リリース作業の省力化もあり、問題がより短い期間で修正され、過去最高のバージョンの Ruby を届けられるようになってます。

セキュリティメンテナンスポリシーの紹介

つい先日となりますが、セキュリティメンテナンスステータスである Ruby 3.1 の最後のバージョンである 3.1.7 と、ノーマルメンテナンスの Ruby 3.2 として最後のリリースの 3.2.8 をリリースしました。

このリリースを持って Ruby 3.1 のメンテナンスとリリースは終了となる見込みです。見込み、と書いたのはこのリリースによって致命的なビルド上の不具合があった場合は 3.1.8 を緊急でリリースしようと思いますが、ないことを祈ってます。また、今後は 3.2 がセキュリティメンテナンスとなります。メンテナンスが行われるとはいえ、1年後にはメンテナンスの終了が予定されているので Ruby 3.3 または 3.4 へのアップグレードを推奨します。

さて、「セキュリティメンテナンス」とは何か、というのはブランチメンテナに委ねられているので、私の場合のポリシーをあらためて文章化しておこうと思います。

  • CVE が発番される脆弱性を修正する、いわゆるセキュリティ Fix
  • サポート対象としている新しいバージョンの OS などでビルドできない、またはインタプリタが動かないという問題を修正する
  • CI やテストの実行対象としているプラットフォームでテストが通らない問題について、テストコードを修正する

セキュリティメンテナンス、というと先頭のものだけを想像しがちですが、ソフトウェアは何もしないでいるとすぐに動かなくなるので、皆さんがプロダクトや開発で滞りなく使えるようにするための問題は修正します。また、リリースの困難さを下げるために、テストコードに限って修正は引き続き行っていきます。

まとめ

以上、バージョニングから、ブランチポリシー、ブランチメンテナンスについて紹介しました。

この辺は Ruby をお使いの皆さんならご存知ですよね、とは思いつつ、新しく Ruby を使い始める人にとっては、「Minor の修正なのに非互換があった!」「3.1 って機能の修正しないの?」など驚きがあるというのをたまに見かけるのであらためてまとめてみました。皆さんの近くに Ruby のバージョンやメンテナンスのポリシーについて知りたいという方に、このエントリを共有してもらえるとありがたいです。