2011-01-16

WebKit はリリースしない

ウェブをみていたらこんな風に書いているページがあった.

WebKitは、現在も改良が加えられ、日々「現在開発中のWebKit」が開発者や先端ユーザー向けに提供されています。 ある程度、安定した機能を次のリリース用として仕様を固めたバージョンが、開発中バージョンとは別に作られ、一般ユーザーにも使えるよう、バグが少ない安定したコードになるまでデバッグが繰り返されます。 そして安定したバージョンを、各ソフトウェア提供企業が採用して、製品に使われるようになるのです。

この説明に間違いは無いと思うけれど, たぶん読んだ人の印象と実体は少し違うと思う. このズレに実害は無いと知りつつ, いい機会なので WebKit のリリースについて私の理解を説明してみたいとおもう.

最近 webkit-dev メーリングリストに "Best way to track feature evolution from release-to-release" という 質問が投稿された. 投稿したのは Motorola TV (のような何か) を開発している開発者らしい. 質問の趣旨は "UI 描画用に WebKit を移植してるんだけど, どのバージョンでどの機能がサポートされてるか調べる良い方法はないの? あとバージョンって User-Agent をみればいいんだよね？" というもの. Darin Adler (WebKit の親玉) からの 返信 はきっちりと彼の期待を裏切った. つまり, 1. バージョンと機能を対応づける良い方法はない (そういう表があれば保守する気はあるけど今はない.) 2. User-Agent の値は Apple の都合で決めたものなので, WebKit プロジェクトとしての共通見解ではない. (ただし多くのブラウザはこれをそのまま使っている.)

WebKit には動作プラットホームごとに "ポート" がある. Qt で動く WebKit は Qt ポート, Chromium で使う WebKit は Chromium ポート, などと呼ばれている. Mac Safari で動くポートは Mac ポートと呼ぶ, こともあるけれど, 単に WebKit と呼ぶことの方が多い気もする. Mac 版が本家大元だから. 各ポートはそれぞれが自分の都合にあわせ勝手にバージョンをつけ "リリース" をしている. そして WebKit 全体としてのリリースはない. バージョンもない. セキュリティ問題の修正等も各ポートがそれぞれ trunk からのパッチを持っていく.

だから今のところ "WebKit のバージョン" を議論するのは難しい. Safari のバージョン, Chromium のバージョン, QtWebKit のバージョン... などには意味があるかもしれない. 各ポートが WebKit trunk のどこから派生したものか, コンテンツの側から簡単にわからないのはたぶん色々な面倒を招いている. 先のスレッドでも trunk のリビジョンを User-Agent に含めればいいのではといった提案があったが, cherry pick をうまく反映できない問題があると指摘されている.

ただ User-Agent の元になるファイルの 履歴 をみると, 最近は月に二回くらい定期的に(リリースとは関係なく)マイナーバージョンを上げているようす. なので User-Agent にある WebKit のマイナーバージョンをみれば, WebKit 共通の何かも少しはわかるのかもしれない... でもブランチでマイナーバージョンを書き換えてる例もあるなー. それやっちゃダメじゃね...?

各ポートのリリース

そんな事情からリリース方法はポート毎に違う.

本家 Mac 版 のリリースは Safari のリリースに足並みを揃えている. だいたい年に一回くらいだろうか. Safari 5 の WebKit 用だと思われるブランチを遡ると 2010/5 月頭の trunk から枝分れしている. Safari 5 のリリースが 2010/6 月だから, ブランチからおよそ一ヶ月でリリースしていることになる. ほんとにそんな短いのか. 私が何か勘違いしている気もする. あるいは Safari の開発が印象よりアグレッシブなのかもしれない. なおバグ修正をしたマイナーリリースはより頻繁に行われている.

Mac 版の親戚である iOS がどうしてるのかはわからない. 見えないところで似たようなことをしてるんだろうと想像するけれど.

GTK ポート は リリースブランチの切られ方 を見る限り毎月定期的にバージョンをつけているようす. ブランチ上に trunk からの修正をマージした形跡がないのは面白い. 人的資源が限られているからだと思う. 変化の大きいプロジェクトに少人数でかかわるとき, ブランチの安定化を諦めるかわりにリリース間隔を縮めておくのはいいアイデアかもしれない. trunk を直せば一ヶ月後にはリリースされるわけだから. ただし他の新しいバグも一緒に...

マイナーリリースはいかにもなさそうというかマイナーとメジャーの区別がなさそうだけれど, ライブラリを配布している 各 linux distros が 少しは細々とした面倒を見ているのかもしれない.

Qt ポート は住み込み先の大規模プロジェクト Qt に足並みを揃える都合からか, もうちょっと色々やっている. 説明用ページもけっこう充実. Qt WebKit の最新バージョン 2.2 はまだリリースされておらず, しかもこのバージョンは trunk ではなく QtWebKit 2.1 をベースにしている. Qt WebKit 2.1 は 2010/7 月の WebKit をベースにしている. つまり最新リリースの QtWebKit は trunk から半年離れている. QtWebKit 2.2 は media と audio を cherry pickと言っているけれど, なかなか大変だろうと思う. マイナーリリース事情はわからず.

Qt WebKit は svn.webkit.org ではなく gitorius.org 上のミラー で リリースブランチを管理している. Qt に倣ったのだろう. Gitorious かっこいいなー.

Chromium ポート は Chromium 本体のリリースサイクルにあわせて WebKit もブランチする. 要するに svn.chromium.org の trunk がブランチされたら WebKit も trunk からブランチする. そのあと beta channel 上で QA が行われ Chromium 本体と WebKit それぞれのバグをなおし, stable としてリリースされる... 細部はちょっと違うかもしれないけどだいたいそんなかんじだったはず. ブランチは svn.webkit.org にある. バージョンの数字はたぶん Chromium のビルド番号みたいな何かだと思いますごめんわかんない... バグフィクスのためのマイナーリリースはしょっちゅうある. 再起動しろといわれたらアップデートがおきたしるし.

バージョンからは見分けられない違い

さてブランチでマイナーバージョンをあげてしまう Mac WebKit と各ポートでの cherry pick を無視すれば, User-Agent のマイナーバージョンを見てだいたいのことがわかる... かというと実際には他の面倒もある.

新しい機能は大抵コンパイルオプションで無効にできる. 実装が十分に洗練されていない, 該当自分のポートへの移植が済んでいないとき, ポートはビルドの設定で該当機能を無効にする. たとえば Safari 5 ではツリーに入っているいくつかの新しい HTML5 のタグが無効にされている. GPU accelerated composition サポートは最初 Mac でしか動かなかった. 縦書き CSS はまだ Mac と一部の Chromium でしか動かない. 計算機資源の限られた環境向けのポートではコードサイズのでかい SVG がよく無効化されている. など.

WebKit はアーキテクチャで可搬性を担保するかわりに, とりあえず Mac で動かして他のポートは各人が頑張って追従するという, 良くいえばソーシャルなアプローチで可搬性を実現している. おかげで野心的な可搬アーキテクチャにありがちな オーバーヘッドなしに新しい機能を取り込んでいける. かわりに皺寄せもリリースの断片化といったソーシャルな部分にあらわれているのはやや悲しい.

一方で可搬性という工学上の問題を高度な設計ではなくバザール的な人海戦術で, しかもいくつもの企業から集まった会社員プログラマの人月で解決していく WebKit の様子は, オープンソースプロジェクトのあり方として面白いとおもう. 最近は Hadoop など企業発ながら同業他社があつまってコミュニティっぽく開発している オープンソースのコードも多い. 他のプロジェクトがどうやって切り盛りされているのかも見てみたい今日このごろです. あらあらかしこ.