Ruby 2.7を最小サポートバージョンに設定

rails/bootsnap

bootsnap 1.23.0では、Ruby 2.7が最小サポートバージョンとなりました。この変更により、Ruby 2.7以降で利用可能なAPIを活用でき、より安全なパス解決処理が可能になります。

背景

File.absolute_path? メソッドの使用がこの変更の直接的な動機です。このメソッドはRuby 2.7で追加されたもので、パスが絶対パスかどうかを判定する際の処理を簡潔にします。PR作成者は「File.absolute_path?を使う必要がある」と述べており、パス処理の改善を目的とした変更であることがわかります。

Ruby 2.6は2022年4月にEOLを迎えており、サポート対象から外すことでメンテナンスコストを削減できます。

技術的な変更

gemspecCI設定Rubocop設定の3箇所でRubyバージョン要件が更新されました。

gemspec の変更:

# 変更前
spec.required_ruby_version = ">= 2.6.0"

# 変更後
spec.required_ruby_version = ">= 2.7.0"

CI設定の変更:

# 変更前
matrix:
  os: [ubuntu, macos, windows]
  ruby: ['2.6']

# 変更後
matrix:
  os: [ubuntu, macos, windows]
  ruby: ['2.7']

テストマトリックスからもRuby 2.7が除外され、3.0以降のバージョンのみがテスト対象になりました。

Rubocop設定の変更:

# 変更前
TargetRubyVersion: 2.6

# 変更後
TargetRubyVersion: 2.7

これに伴い、Ruby 2.7以降で不要となった警告抑制コードが削除されました。alias_methodを使った重複メソッド定義の警告を避けるためのRubocopディレクティブ(# rubocop:disable Lint/DuplicateMethods)が2箇所で削除されています。また、super(hash)superに簡潔化され、hash = hash ^ bytehash ^= byteに書き換えられるなど、Ruby 2.7以降の構文が採用されています。

依存関係の整理:

# 変更前
gem "rubocop", "~> 1.50.2" # Ruby 2.6 support
gem "benchmark"
gem "ostruct"
gem "base64"

# 変更後
gem "rubocop"

Ruby 2.6サポートのためにバージョンを固定していたRubocopが最新版に更新され、Ruby 2.7以降で標準ライブラリに含まれるbenchmarkostructbase64の明示的な依存が削除されました。

設計判断

段階的なバージョンアップではなく、直接Ruby 2.7へ移行する方針が採用されました。PR内にRuby 2.7を選択した詳細な理由は記載されていませんが、File.absolute_path?の利用が主な動機であることから、特定のAPIの必要性が判断基準になったと考えられます。

gemspecではadd_runtime_dependencyadd_dependencyに変更されています。この変更は機能的には等価ですが、より一般的な記述方式への統一と見られます。

テストコードでは"/dev/null"File::NULLに置き換えられており、プラットフォーム非依存な記述への改善も行われています。これはRuby 2.7以降のクロスプラットフォーム対応の改善を活用したものです。

まとめ

本PRは、Ruby 2.7のAPIを活用するための基盤整備として、最小サポートバージョンを引き上げた変更です。gemspec、CI、Rubocopの設定を一貫して更新し、Ruby 2.6サポートのための回避コードを削除することで、コードベースの保守性を向上させています。File.absolute_path?の利用という明確な技術的理由のもと、EOL済みバージョンのサポート終了という自然な判断が行われました。

記事メタデータ

Generated by:
Claude Sonnet 4.5 for DiffDaily

この記事はAIによって自動生成されています。内容の正確性については、必ずソースコードやPRを確認してください。

品質レビュー結果

Review Status:
承認済み
Review Count:
1回
Reviewed by:
Gemini 2.5 Pro for DiffDaily

Review Criteria:

記事構成 ✓ OK

Title, Context, Technical Detailの存在と明確さ

カスタムMarkdown構文 ✓ OK

シンタックスハイライト・GitHubリンク記法の正確性

対象読者への適合性 ✓ OK

エンジニア向けの適切な技術レベルと表現

パラグラフ・ライティング ✓ OK

トピックセンテンス・1段落1トピック・段落長

Diff内容との照合 ✓ OK

コードブロックとDiff内容の一致

技術用語の正確性 ✓ OK

技術用語の正確な使用

説明の技術的正確性 ✓ OK

技術的主張の正確性と論理性

事実の突合 ✓ OK

PR情報による主張の裏付け(ハルシネーション検出)

数値・固有名詞の確認 ✓ OK

PR番号・コミットID・バージョン等の正確性

タイトル・説明との一致 ✓ OK

記事タイトル・説明とPR内容の一致

外部知識の正確性 ✓ OK

PRに記載のない外部知識(LTS、サポート状況など)の不使用

時間表現の正確性 ✓ OK

時間表現がPR情報と一致しているか