Edited at

Ruby と Rails をいつアップデートすればいいか、雑に調べた

Ruby・Railsに限らず、ライブラリの古いバージョンを使い続けるのは、セキュリティ的にも開発効率的にも良くありません。

しかし、アップデートはアプリケーションの機能を向上させるものではありませんから、機能開発や不具合修正の方が優先されがちです。そのため、古いバージョンが放置されないようにするには、あらかじめ年間計画の中にアップグレード作業を織り込んでおくのが1つの方法です。

ところで、RubyもRailsも、マイナーバージョンも含めれば2・3ヶ月に1回リリースされます。アップデートはいつ行えばいいのでしょうか?


RubyとRailsのリリース周期

アップデート計画を考える上では、機能の追加変更がある X.Y.0 (マイナーバージョンアップ)と、大きな不具合が見つかることが多いとされる X.Y.1 のリリースが重要です。以下で X.Y.0, X.Y.1 のリリース日を調べました。

Ruby のX.Y.0 は毎年12月25日にリリースされ、早ければ翌2月にX.Y.1 がリリースされるようです。

Rails のX.Y.0 は決まったルールがあるわけではないようですが、毎年4月ごろにリリースされるようです。X.Y.1 は、最も早いv5.1.1では半月後にリリースされています。

また、Ruby・Railsともにある時点で過去のマイナーバージョンがサポート対象から除外されます。

Rubyでは、不具合修正は最新 + 前世代のみ、セキュリティ問題は最新 + 前世代 + 前々世代世代が対象です。

Railsでは、不具合修正は最新世代のみ、セキュリティ問題は最新 + 前世代が修正対象です(ドキュメント)。また、重大なセキュリティ問題は(今のところ)3世代前まで修正対象です。

Ruby:

バージョン
リリース日
間の日数

v2_1_0
2013-12-25

v2_1_1
2014-02-24
61

v2_2_0
2014-12-25

v2_2_1
2015-02-27
64

v2_3_0
2015-12-24

v2_3_1
2016-04-25
123

v2_4_0
2016-12-23

v2_4_1
2017-03-22
89

v2_5_0
2017-12-25

v2_5_1
2018-03-28
93

Rails:

バージョン
リリース日
間の日数

v4.1.0
2014-04-08

v4.1.1
2014-05-05
27日

v4.2.0
2014-12-19

v4.2.1
2015-03-19
90日

v5.0.0
2016-06-30

v5.0.1
2016-12-21
174日

v5.1.0
2017-04-27

v5.1.1
2017-05-12
15日

v5.2.0
2018-04-09

v5.2.1
2018-08-07
120日

なお、「リリース日」は以下のようにGitのコミット日時をとったものなので実際のリリース日とは異なります。

git clone httos://github.com/ruby/ruby ~/Documents/ruby

cd ~/Documents/ruby
$ for v in v2_1_0 v2_1_1 v2_2_0 v2_2_1 v2_3_0 v2_3_1 v2_4_0 v2_4_1 v2_5_0 v2_5_1; do echo -n $v' '; git log -n 1 --pretty=%aI $v | cut -f 1 -d T; done

git clone httos://github.com/rails/rails ~/Documents/rails
cd ~/Documents/rails
for v in v4.1.0 v4.1.1 v4.2.0 v4.2.1 v5.0.0 v5.0.1 v5.1.0 v5.1.1 v5.2.0 v5.2.1; do
echo -n $v' '
git log -n 1 --pretty=%aI $v | cut -f 1 -d T
done


アップデートプランを考える

アプリケーションの違いによって、アップデートの戦略がいくつか考えられます。

2年周期のアップデート

あまり開発が活発ではないアプリケーション向けの戦略です。Railsのマイナーバージョンのサポート切れに合わせてアップデートし、最低限、重大なセキュリティ問題の修正対象から漏れないようにします。

なお、Railsのリリース日が一定しないので、年間計画を建てる場合は「2年おきの●月に決まった期間にその時点の最新版にアップデート」のような計画の立て方にせざるを得ないでしょう。具体的にはRuby・Railsの最初の不具合修正が(もしあれば)出ている6月ごろに行うのが良さそうです。

1年周期でアップデート

Railsのマイナーバージョンは最新に保つ戦略です。たいていのアプリケーションはこの戦略が良さそうです。

X.Y.0 と X.Y.1 のどちらにアップデートするかは好みが分かれるかもしれません。昔は「初期リリースには不具合が多いので避ける」というのが常識でしたが、最近のRubyやRailsを見ると初期リリースに重大な不具合があるのは少ない気も・・・。メジャーバージョンアップはまた別ですが。

しかし、どちらにせよRailsのリリース日が不定期なので毎年6月にアップデートといった計画の立て方になりそうです。

ローリングアップデート

Ruby・Railsのバグフィックスリリースを含めた全てのリリースがあるたびに即座にアップデートする戦略。ある意味理想的です。しかし、アップデートをしたときは普通はアプリケーションのテストが必要になるはずで、テストの自動化が必須になるでしょう。