Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Rubyの安定版を保守する意義 / Why we maintain stable versio...
Search
usa
July 17, 2020
Programming
0
98
Rubyの安定版を保守する意義 / Why we maintain stable versions of Ruby?
2020年7月17日 Ruby Association Activity Report
Rubyアソシエーションの「Ruby安定版保守事業」について、担当者からその内容と目的を紹介したものです。
usa
July 17, 2020
Tweet
Share
More Decks by usa
See All by usa
WindowsにおけるRubyのエンコーディングの話 Ruby3版/Ruby's encoding on Windows at Ruby3
unak
0
340
PIXIV TECH FES. short session / What kind of contribution to OSS is really pleased?
unak
0
2k
Internal of the image processing required on the developing of web applications
unak
5
4.9k
Schrödinger's branch, or Ruby is dead every year
unak
0
670
talk about IO
unak
4
1.8k
Other Decks in Programming
See All in Programming
約9000個の自動テストの 時間を50分->10分に短縮 Flakyテストを1%以下に抑えた話
hatsu38
24
12k
デプロイを任されたので、教わった通りにデプロイしたら障害になった件 ~俺のやらかしを越えてゆけ~
techouse
53
34k
Streams APIとTCPフロー制御 / Web Streams API and TCP flow control
tasshi
2
340
GCCのプラグインを作る / I Made a GCC Plugin
shouth
1
160
Generative AI Use Cases JP (略称:GenU)奮闘記
hideg
0
190
Duckdb-Wasmでローカルダッシュボードを作ってみた
nkforwork
0
100
What’s New in Compose Multiplatform - A Live Tour (droidcon London 2024)
zsmb
1
440
Nurturing OpenJDK distribution: Eclipse Temurin Success History and plan
ivargrimstad
0
400
From Subtype Polymorphism To Typeclass-based Ad hoc Polymorphism- An Example
philipschwarz
PRO
0
190
カラム追加で増えるActiveRecordのメモリサイズ イメージできますか?
asayamakk
4
1.9k
破壊せよ!データ破壊駆動で考えるドメインモデリング / data-destroy-driven
minodriven
17
4.3k
GitHub Actionsのキャッシュと手を挙げることの大切さとそれに必要なこと
satoshi256kbyte
5
410
Featured
See All Featured
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.1k
How STYLIGHT went responsive
nonsquared
95
5.2k
Raft: Consensus for Rubyists
vanstee
136
6.6k
Measuring & Analyzing Core Web Vitals
bluesmoon
2
75
Build The Right Thing And Hit Your Dates
maggiecrowley
33
2.4k
Practical Orchestrator
shlominoach
186
10k
A Philosophy of Restraint
colly
203
16k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
26
1.4k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
131
33k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5k
Fantastic passwords and where to find them - at NoRuKo
philnash
50
2.9k
A designer walks into a library…
pauljervisheath
202
24k
Transcript
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