日にリリースされました。エキサイティングな新機能をカバーし、いくつかの有用な変更点をハイライトし、少しの、コードの書き換えを要する互換性のない変更点について指摘します。開発は、リリースとリリースの間で止まることはなく、バグフィックスと改善はとめどなく、日夜提出されます。ログを調べてください。移行した結果改善されたコミュニケーションのおかげです。リリースと考えることが出来ます。リリースが作成されることをリクエストしました。ツリーの状態と同等です。前方互換を保障するために少しの修正を受け取りました。進化の一部であり、側枝ではありません。ファイナライズはその一ヶ月かそこらで行われるよう計画されました。移行には少しばかりコードの破壊を伴うようです。移行による別の破壊ラウンドがやってきます。移行したほうが良いでしょう。月の間に行われたからなのです。よって利用出来るようになったツールの使用を始めました。プロジェクトページで利用可能なバグトラッキングとパッチ管理ツールを使ってください。ソースコードを含む、バージョンコントロールされたレポジトリです。人ほどいて、全てのパッチはその中の一人が精査とチェックをする必要がありました。明らかにこれはスケーラブルではありませんでした。人の人々が変更をチェックイン出来るようになっていました。これは大規模な変更、これまでであれば小さなコア開発グループによるフィルタを経由しなければならないために試みられなかったような、大規模な変更を可能にしています。メーリングリストでの承認を得たのち、彼は立て続けにチェックインを開始しておよそ一週間ほどで終わらせ、ほかの開発者たちも手助けに参加し、そして作業は完了しました。人だけだったならば、おそらくそのタスクはこう見做されたでしょう:「素晴らしい。時間と労力に見合わない」。実現することはなかったことでしょう。サービスを使うことへのシフトは、開発の目覚しいスピードアップをもたらしました。パッチはいまや、提出され、コメントされ、提出者以外の別人によって改定されて戻ってきて、などなどが、パッチがチェックインの価値があると判断されるまで行われています。バグは唯一つの中央保管庫で追跡され、修正には特定の誰かを割り当てることが出来、そして私たちはオープンバグを進捗の指標として考えることが出来ます。開発者には今や以前よりもたくさんの処理すべき電子メールがあり、より多くメーリングリストに追従しなければならず、そして新しい環境のための特別なツールを要しました。スクリーンスクレイパを書きました。簡単にコードを追加出来るようになったことは、当初少し苦痛を大きくしました。コードが不十分なままだったり、開発グループからのはっきりとした承諾のないままチェックインされたりするといったことです。グループが使っているようなものにいくらか似たものです。開発者は変更にほとんど興味がないけれどもやや肯定、否定の傾向であることを意味します。侯に大衆の民意を伝えるものであることです。彼は投票結果をそれでも無視出来ますし、コミュニティが異論を唱えようが変更を承認したり却下したり出来ます。新機能について記述する設計文書です。機能についての技術的な仕様とその機能の論拠(理論)を簡潔に伝えるべきです。なされる設計決断の文書化のための最上位の機構となることを意図しています。著者にはコミュニティ内の合意形成を行うこと、反対意見を文書化することの責務があります。