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
97
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
320
PIXIV TECH FES. short session / What kind of contribution to OSS is really pleased?
unak
0
1.9k
Internal of the image processing required on the developing of web applications
unak
5
4.8k
Schrödinger's branch, or Ruby is dead every year
unak
0
660
talk about IO
unak
4
1.7k
Other Decks in Programming
See All in Programming
Using Livebook to build and deploy internal tools @ ElixirConf 2024
hugobarauna
0
250
マルチモジュールにおけるテスト最適化
fxwx23
0
210
LangChainの現在とv0.3にむけて
os1ma
4
920
rails_girls_is_my_gate_to_join_the_ruby_commuinty
maimux2x
0
200
僕が思い描くTypeScriptの未来を勝手に先取りする
yukukotani
9
2.4k
Hono・Prisma・AWSでGeoなAPI開発
nokonoko1203
5
680
LangChainでWebサイトの内容取得やGitHubソースコード取得
shukob
0
160
unique パッケージから学ぶ interning と weak reference @ Asakusa.go#3
karamaru
2
810
AndroidアプリのUIバリエーションをあの手この手で確認する / Check UI variations of Android apps by various means
tkmnzm
1
170
大公開!iOS開発の悩みトップ5 〜iOSDC Japan 2024〜
ryunakayama
0
190
Understand the mechanism! Let's do screenshots tests of Compose Previews with various variations / 仕組みから理解する!Composeプレビューを様々なバリエーションでスクリーンショットテストしよう
sumio
3
790
KSPの導入・移行を前向きに検討しよう!
shxun6934
PRO
0
280
Featured
See All Featured
Designing Experiences People Love
moore
138
23k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
354
29k
Keith and Marios Guide to Fast Websites
keithpitt
408
22k
Being A Developer After 40
akosma
84
590k
No one is an island. Learnings from fostering a developers community.
thoeni
18
2.9k
Building Better People: How to give real-time feedback that sticks.
wjessup
359
19k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
230
17k
10 Git Anti Patterns You Should be Aware of
lemiorhan
653
58k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
36
2.1k
Designing for humans not robots
tammielis
248
25k
A Modern Web Designer's Workflow
chriscoyier
691
190k
VelocityConf: Rendering Performance Case Studies
addyosmani
322
23k
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