Drupal 8のマイナーリリースのセキュリティ保護期間の拡大について

Drupal 8.0の公開以来、私たちは6か月ごとに新しいマイナーリリースを公開してきました。私は、この偉業を成し遂げたコミュニティをとても誇らしく思います。Drupal 8より前の時代では、重要な新機能のほとんどは、Drupal 6やDrupal 7といったメジャーリリースでしか追加されることはありませんでした。私たちの新しい定期リリースにより、年に2回のマイナーリリースという一貫性のある予測可能な形で、重要な新機能を公開できるようになりました（Drupal 8.6に搭載された数多くの新機能がその例です)。

ただし、バグ修正とセキュリティ保護の両方が積極的にサポートされるのは、最新のマイナーリリースだけでした。新しくリリースされる各マイナーバージョンについて、1つ前のバージョンから最新バージョンへの移行期間として私たちが設定した時間は1か月でした。サイト所有者にアップグレードの時間を提供するため、この1か月の移行期間中は、1つ前のマイナーリリースに関するセキュリティ上の問題は公表を控えました。

これまでの移行期間は1か月

従来：
Drupalの新しいマイナーリリースが公開されると、
1か月以内にアップグレードしないとセキュリティ更新が提供されなくなる。

Drupal 8.0公開以来のマイナーリリースに関するセキュリティ方針の説明図。1つ前のマイナーリリースのセキュリティが保護される期間が1か月であることを示している。出典は、Drupal.org の issue #2909665「Extend security support to cover the previous minor version of Drupal」、およびDrupal EuropeでのDriesNote（Dries氏の講演）。

過去3年間を通じ、最新のマイナーリリースに1か月でアップデートすることは、ユーザーにとって容易でないことがわかってきました。Drupalのマイナーアップデートには、依存関係の更新、内部的なAPIの変更、またはコア以外の拡張モジュールからコアに移された機能が含まれる可能性があります。こうした変更の準備やテストは、サイト所有者にとって時間のかかる作業であり、1か月の移行期間では必ずしも十分とは言えません。

DrupalCon Nashvilleにおいて、私たちはマイナーリリースのセキュリティ保護期間の延長に前向きであることを宣言しました。2018年を通して、Drupal 8のリリース管理者は試みに静かに取り組んできました。今年、1つ前のマイナーリリースに対して複数のセキュリティリリースが提供されたことに気づいたかもしれません。この試みにより、リリースプロセスへの影響を理解し、今後さらに取り組むべき残された作業について学ぶことができました。この試みの結果については、#2909665「Extend security support to cover the previous minor version of Drupal」を参照してください。

この試みが成功したことを共有できて嬉しく思います。結果として、マイナーリリースのセキュリティ保護期間は6か月に延長されました。サイト所有者は、マイナーリリース間のアップグレードを行うために、これまでの1か月に代わる6か月という時間を確保したわけです。チームは、この時間をアップデートの計画、準備、およびテストに充てることができます。各リリースには、通常のバグ修正サポート期間6か月と、それに続くセキュリティ保護期間の6か月、合計で1年間の生存期間が与えられることになります。これは、Drupalのサイト所有者にとっての大勝利です。

今後の移行期間は6か月

今後：
各マイナーリリース間の移行期間は6か月となり、
各リリースに合計で12か月のセキュリティサポートが与えられる。

マイナーリリースに対する新しいセキュリティ方針の説明図。各マイナーリリースのセキュリティ保護期間が6か月に延長されたことを示している。出典は、Drupal.org の issue #2909665「 Extend security support to cover the previous minor version of Drupal」、および Drupal Europe での DriesNote（Dries 氏の講演）。

この新しい方針が適用されるのは、Drupal 8.5以降のDrupal 8コアのみで、かつ対象がセキュリティ上の問題だけである点に注意が必要です。セキュリティ以外のバグ修正は、従来どおり、積極的にサポートされるリリースにのみコミットされます。

この新しい方針によってDrupal 8.5.xのセキュリティ保護期間が延長されますが、他方その対象となる通知を正しく受けるには、サイト所有者が今後のDrupal 8.5リリースに更新する必要があります。

次のステップ

ユーザー体験に関しては、サイト所有者がセキュリティ更新の警告を受け取る方法について、なお解決すべきいくつかの課題があります。発生する可能性がある極端な事例のすべてをまだ処理できているわけではなく、アップデートの際に発生する潜在的な動きを明らかにする必要があります。

また、モジュール開発者が、自分のプロジェクトのあるリリースが特定のDrupalコアのバージョンでのみ動作することを宣言する必要性についても認識しています。コア以外のセマンティックバージョニングのサポートや、モジュールのバージョン依存性定義に関する未解決の問題を解決することで、コア以外のプロジェクト開発者がこの方針をより適切にサポートできるようになるでしょう。残された作業に関与したいという方は、Drupal.orgで方針やロードマップの課題を調べれば、関係する課題や残りの作業が見つかります。

この記事を共同で執筆してくれたJessとJeff Beemanに感謝します。