Rubyの安定版を 保守する意義 pixiv Inc. NAKAMURA Usaku 2020.7.17

2 自己紹介 ● ピクシブ株式会社 ○ 技術開発本部配信技術部マネージャ ○ ● Rubyコミッタ ○ Windows担当 ○ 安定版リリースマネージャ usa @unak

Rubyの開発プロセス 3 ● master (trunk) ○ 開発陣が日々いじっているところ ● 毎年クリスマスにここから新しいブランチが生えて新バージョンがリリースされる ○ 2018年12月25日 ruby_2_6 2.6.0 ○ 2019年12月25日 ruby_2_7 2.7.0 ○ 2020年12月XX日 ruby_3_0 3.0.0 ……？ ● ここ数年はリリースマネージャは成瀬さん

Rubyの開発プロセス 4 ● つまり毎年新しいブランチが増える ○ この、masterではないブランチとそこからのリリースが「安定版」 ● ここ数年は、基本的に3本の安定版を維持している ○ 新しいブランチが生えたら一番古いものは EoL ○ なので「Rubyは毎年死ぬ」

安定版ブランチ ruby_2_7 (2019年12月～) ● 最新リリースは Ruby 2.7.1 ● リリースマネージャはnagachikaさん ○ ここ数年は1本目のブランチはnagachikaさんが見てくれている 5

安定版ブランチ ruby_2_6 (2018年12月～) ● 最新リリースは Ruby 2.6.6 ● リリースマネージャはusa ● Ruby安定版保守事業の対象 6

安定版ブランチ ruby_2_5 (2017年12月～2021年3月(予定)) ● 最新リリースは Ruby 2.5.8 ● リリースマネージャはusa ● セキュリティメンテナンスブランチ ○ 単なるバグの修正も入れない ○ 原則としてセキュリティ問題であると判断された変更のみバックポート 7

安定版ブランチ ● 2019年12月：masterからruby_2_7ブランチが切られてRuby 2.7.0がリリース ● 2020年3月末：ruby_2_4ブランチがEoL ● 2020年4月：ruby_2_7の担当が成瀬さんからnagachikaさんに引き継ぎ 　　　　　 ruby_2_6の担当がnagachikaさんからusaに引き継ぎ 　　　　　 ruby_2_5がセキュリティメンテナンスフェーズに移行 (担当usaのまま) ● ここ数年はだいたいこんな感じ ● なので、常に3本の安定版ブランチが維持されている (12月～3月は4本) 8

安定版ブランチ Q： なんで3本なの？ A： マンパワーの限界だから ● Ruby安定版保守事業が始まる前はmaster以外は1, 2本の維持が限界だった ● nagachikaさんを始めとする関係各位のご協力と、 Ruby安定版保守事業のおかげで3本 の安定版ブランチを維持し続けられるようになった 9

Ruby安定版保守事業 ● 3本の安定版ブランチのうち、2番目のもの(現在はruby_2_6)が対象 ○ 加えて緊急セキュリティ対応があるので、必要が生じれば 1番目のブランチ(現在は ruby_2_7)を触る可能性もなくはないが、今のところ起きてない ● 2012年10月に事業スタート ○ ruby_1_9_3 (当時の2番目のブランチ) ○ 当初からusaが担当 ○ 公募なのでusaじゃなくても応募できます 10

Ruby安定版保守事業 なんで2番目のブランチが対象？ ● 「誰もやりたがらない方」を事業とする ○ 古いブランチほど誰もやりたがらない ● 毎年新しいブランチが生えるということは、 2番目は2年目に入っている ○ つまり、2番目を1年間保守すれば、Rubyの各安定版が最低2年間強は維持されるこ とが保証できる 11

Ruby安定版保守事業 ● 1番目(現ruby_2_7) ○ masterからのパッチは分岐から間がないのでだいたいそのままあたる ○ 単なるバグだけでなく、仕様的変更もままある ● 2番目(現ruby_2_6) ○ masterからのパッチは簡単にはあたらなくなってくる (体感で50%くらい) ■ 場合によっては同じ趣旨の変更の再実装もなくはない ○ 基本的にはバグ対応のバックポートのみなので面白味はあまりない ● 3番目(現ruby_2_5) ○ masterからのパッチはほぼあたらない ○ そもそもセキュリティ対応の頻度自体が極めて低い 12

安定版の保守が必要な理由 ● Rubyの開発者は最新of最新にしか興味がない ● Rubyの利用者はリリースされたものしか使わない ● 利用者の期待は「バグ修正だと思ってバージョンアップしたら仕様変更が紛れ込んでいて 自分のコードが正しく動かなくなった」がないこと ● 開発者と利用者の間のギャップを埋めるには、開発版 (master)とリリース用ブランチを分 離しておくしかない ○ ……ということを、過去の経験から学んだ 13

安定版の保守が必要な理由 ● Rubyの開発者はRubyの進化(というか進化させること)に興味がある ● RubyのユーザーはRubyの進化に興味がない……わけでもないが、基本的には自分のプロ ダクトが中心。Rubyはそれを実現するための道具に過ぎない ● つまり、あんまりころころRubyが変わるのは割と迷惑 ● 使ってるバージョンのRubyがすぐに保守されなくなるのも困る ○ 2番目を安定版保守事業で支えているのは少しでも長く維持するため 14

安定版の保守が必要な裏の理由 ● masterに新機能をぶちこむため ○ 互換性はとても大事、わかる ○ でも、言語を進化させていくためには、時として互換性の破壊も必要 ○ 毎年互換性が破壊されるとユーザーはついてこれない ● 安定版があると、ユーザーは毎年互換性破壊を伴いうる Rubyのバージョン切り替えを強い られることがなくなる ○ 1年ごと or 2年ごと or 3年ごと を自分のペースで選べる ● それが担保されていれば、安心して masterで互換性を破壊できる……かも？ 15

安定版保守の課題 ● 本当は1番目のブランチも事業としてやるべきかもしれない ○ 今はnagachikaさんに負担をかけていて申し訳なさがある 16

安定版保守の課題 ● もうちょっと長い期間の保守が必要かも ○ 今は3年ちょい維持されているが、全部とは言わないが 5年あるいは7年とかいうスパ ンで維持されるブランチもあった方がいいかも ○ 例えば、LTS(Long Time Support)バージョンのようなブランチを時々作るとか 17

安定版保守の課題 ● 古いバージョンの存在がユーザーの新機能の利用を阻害しうる ○ アプリケーション開発者は、自分が使う Rubyバージョンに合わせたコードを書けばい いのであまり問題はない ○ ライブラリ開発者は、基本的に今生きている全ての Rubyバージョンで動くように書く必 要がある ■ 「面倒だから古いバージョンで動かなくてもいいか」 ● 前方互換性がない変更をmasterに入れにくくなる ■ 「面倒だから新しいバージョンで動かなくてもいいか」 ● ユーザーが古いバージョンにとどまってしまう ● コミュニティ分断 (c.f. Ruby 1.8→1.9、Python2→Python3) 18

まとめ ● Ruby安定版保守事業は、ユーザーのためであると同時に、 Rubyの開発を促進するために 行われている ● 事業の対象外のところで大きな貢献をしてくれている人たちのおかげで成り立っている ● 課題はあるので、今後発展的に解決していけるといいな 19