ChromeプロジェクトのテクニカルプログラムマネージャーであるAnthony Laforgeは、新しいサイクルについて、そして一般的に言って 「Chromeを更新する包括的な哲学」についてプレゼンテーションを行いました。
Anthony La Forgeによると、Google ChromeのリリースサイクルはWeb 2.0アプリケーションまたはWebサイトの開発に似ています。 バージョン番号はなく、プロセスは完全に流れています。 Chromeの場合、各ユーザーは安定性のレベルに応じて自分のブラウザーの更新チャネルにサブスクライブし、アップグレードはバックグラウンドで自動的に行われます。
それが以前のやり方です。 すべての開発者は、プロジェクト開発のメインラインでほぼ常に作業を行っており、個々のブランチはメインラインのいくつかのポイントから離れています。 ブランチは安定し、そこから変更を取り込みます（つまり、すべてが最初にメインラインに落ちます）。
実際には、最終ベータ版では約500個のパッチをマージし、安定化に数週間を費やす必要がありました。 その結果、最終的なベータ版はさらに1〜3か月後にリリースされ、ほとんどの場合、計画された13週間のスケジュールから外れました。 開発者は、非常事態の後、常に荒廃したと感じていました。 このリリースで機能をアナウンスするために急いで作業しなければならなかったたびに、期限が切れていたなど。
これはすべて長い間続いており、最終的にアンソニーラフォージは状況を何らかの形で改善する必要があると判断しました。 最初は、6週間の開発と6週間のベータを含む単純化された12週間のサイクルに切り替えることが計画されていました。 対応する図をコンパイルした後、開発の3つのブランチを使用すると、2つの並行して重複するリリースを作成できることがわかりました。これにより、安定したリリースが約6週間ごとにリリースされます。
もちろん、このアプローチはパッチなどをマージする問題を解決するものではないため、サポート、ローカライズ、マーケティング（リリースマーケティングから機能マーケティングに移行することは可能ですか？）の関連するChromeグループとのブレーンストーミングおよび協議の後、システムを改善することが決定されました。 一般に、新しいスケジュールは11週間の重複サイクルを形成しますが、これはこれまでのところ時計のように機能します。
