Django のリリースプロセス

公式リリース

バージョン 1.0 以降から、Django のリリース番号は以下の規則に従って付けられています。

• バージョン番号は、A.B または A.B.C の形式で表される。
• A.B は フィーチャーリリース 版の番号です。大抵の場合、それぞれのバージョンで、前回のリリースとの後方互換性が保たれます。
• C は、パッチリリース のバージョン番号で、バグフィックスとセキュリティリリースが追加されるたびに数字が1つ増えます。このリリースでは、前回のパッチリリースに対して 100% の後方互換性が保証されています。唯一の例外は、セキュリティやデータの喪失の問題によって、後方互換性を修正するために後方互換性を破らざるをえない場合のみです。このようなことが起こった場合には、パッチリリースが出された場合には、リリースノート内に更新の詳細な手順が書かれます。
• 新しいフィーチャーリリースの前に、アルファ、ベータ、およびリリース候補版が作られます。これらのリリースのバージョン番号は A.B alpha/beta/rc N の形式で表され、バージョン A.B の N番目の アルファ/ベータ/リリース候補版であることを意味します。

git では、それぞれの Django リリースに対して、Django のリリースキーでサインされた、バージョン番号を指すタグが付与されています。さらに、一連のリリースはそれぞれ自分のブランチを持ち、stable/A.B.x と呼ばれ、バグフィックスやセキュリティのリリースは、このブランチから作られます。

Django プロジェクトでセキュリティ対策の新しいリリースを公開する方法について詳しく知りたければ、Django のセキュリティポリシー を読んでください。

フィーチャーリリース

フィーチャーリリース (A.B、A.B+1 など) は、だいたい8ヶ月ごとに公開されます。詳しくは release process を読んでください。このリリースには、新機能や既存の機能への改良などが含まれます。

パッチリリース

パッチリリース (A.B.C、A.B.C+1 など) は必要に応じて公開されます。このリリースでは、バグフィックスやセキュリティ問題へのパッチが含まれます。

このリリースでは、セキュリティ問題の解決やデータの損失を避けられない例外的な場合を除いて、対応するフィーチャーリリースとの 100% 後方互換性が保証されています。そのため、「最新のパッチリリースは更新するべきでしょうか？」という質問に対する答えは、常に「はい」です。

長期サポートリリース

特定のフィーチャーリリースは、長期サポート (long-term support; LTS) リリースに指定されます。このリリースは、通常3年間の保証期間内であれば、セキュリティ問題とデータ損失問題へのパッチが適用されることになっています。

長期保証に指定されたリリースを確認するには、the download page を見てください。

リリース周期

Django 2.0 から、緩い形で セマンティックバージョニング を採用します。LTSの次のバージョンは必ず、".0" に上げられます。例えば、 2.0, 2.1, 2.2 (LTS), 3.0, 3.1, 3.2 (LTS), という具合です。

SemVer を使用すると、リリースの互換性が一目でわかりやすくなります。また、互換性のシムがいつ削除されるかを予測するのにも役立ちます。これは、各機能リリースが引き続き、非推奨のパスが可能でないか、またはコストに見合わない場合に限り、いくつかのドキュメント化された後方互換性のない変更を持ち続けるため、純粋な形の SemVer ではありません。また、LTS リリース (X.2) で開始された非推奨は、少なくとも2つの機能リリースの間、非推奨のシムを保持するという私たちのポリシーに対応するため、非ドットゼロリリース (Y.1) で削除されます。次のセクションに進んで、例を読んでください。

非推奨のポリシー

新しいフィーチャーリリースでは、過去のリリースにある特定の機能が非推奨になることがあります。過去のフィーチャーリリース A.x のある機能が新しいフィーチャーリリースで非推奨になった場合、すべての A.x のバージョン (x の全バージョンに対して) では、それまで通りに機能し続けますが、警告が出るようになります。非推奨になった機能は、バージョン B.0 のリリースで削除されます。ただし、機能の非推奨が A.x の最後のフィーチャーリリースで行われた場合に限り、最低でも2つのフィーチャーリリースで非推奨期間が続いた後に、バージョン B.1 のリリースで削除されます。

したがって、たとえば、Django 4.2 である機能を非推奨にすることを決定した場合、その機能は次のような過程をたどることになります。

• Django 4.2 には後方互換性のある機能のレプリカが含まれ、RemovedInDjango51Warning が発生します。
• Django 5.0（4.2 の次のバージョン）は、後方互換性のあるレプリカを引き続き含んでいます。
• Django 5.1 では、この機能が完全に除外されます。

警告はデフォルトで表示されません。これらの警告の表示を有効にするには、python -Wd オプションを使用します。

より一般的な例では、次のようになります。

• X.0
• X.1
• X.2 LTS
• Y.0: X.0 および X.1 で追加された非推奨のシムを削除します。
• Y.1: X.2で追加された非推奨のシムを削除します。
• Y.2 LTS: 非推奨のシムは削除されません (Y.0 はサポートされていませんが、サードパーティアプリは LTS から LTS へのアップグレードを容易にするために X.2 LTS までの互換性を維持する必要があります)。
• Z.0: Y.0 および Y.1 で追加された非推奨のシムを削除します。

関連情報として、 Deprecating a feature ガイドも参照してください。

サポートバージョン

Django の開発チームは、常時さまざまなレベルでリリースセットへのサポートを提供しています。詳しくは、ダウンロードページの サポートバージョンのセクション にある、各バージョンに対する現在のサポート状況のリストを見てください。

• 現在の開発ブランチ main は、大規模なリファクタリングを必要とする新機能とバグ修正を受け取ります。

• メインブランチに適用されたパッチは、重大な問題を修正する場合に限り、それが属する機能リリースシリーズの最新フィーチャーリリースブランチにも適用され、次のパッチリリースでリリースされなければなりません:

  • セキュリティ上の問題。
  • データ損失のバグ。
  • クラッシュのバグ。
  • 最新の安定版リリースの新機能における主要な機能バグ。
  • 現在のリリースシリーズで以前のバージョンの Django から導入されたリグレッション。

  一般的な原則として、リリースを最初から阻止する可能性があったバグ (リリースブロッカー) に対する修正は、最後の機能リリースにバックポートされます。

• セキュリティ修正とデータ損失のバグは、現在のメインブランチ、最後の2つの機能リリースブランチ、およびその他のサポートされている長期サポートリリースブランチに適用されます。

• ドキュメントの修正は、一般的に最後のリリースブランチにもっと自由にバックポートされます。それは、最新リリースのドキュメントが最新かつ正確であることが非常に有利であり、リグレッションを導入するリスクがそれほど心配されないためです。

具体的な例として、Django 5.1 と 5.2 のリリースの中間点にある時点を考えてみましょう。この時点で:

• 新機能は開発のメインブランチに追加され、Django 5.2としてリリースされます。
• 重大なバグ修正は stable/5.1.x ブランチに適用され、5.1.1、5.1.2 などとしてリリースされます。
• データ損失の問題に対するセキュリティ修正とバグ修正は、main と stable/5.1.x、stable/5.0.x、そして stable/4.2.x (LTS) のブランチに適用されます。これらは 5.1.1、5.0.5、4.2.8 などをリリースします。
• ドキュメントの修正は、main に適用され、容易にバックポート可能であれば、最新の安定ブランチ 5.1.x にも適用されます。

リリースプロセス

Django は期間に基づいたスケジュールを採用しています。フィーチャーリリースは約8ヶ月ごとにリリースされます。

それぞれのフィーチャーリリースの公開後、リリースマネージャは次のフィーチャーリリースのスケジュールを告知します。

リリースサイクル

それぞれのリリースサイクルは、以下の3つのパートからなります。

フェーズ1: 機能の提案

リリースプロセスの最初の段階には、次のバージョンに含める主要な機能を何にするかを決定することが含まれます。これには、それらの機能に関するかなりの予備作業が含まれるべきです。実際に動くコードの量はその大規模な設計を上回ります。

今後のリリースの主要な機能は、たとえば https://code.djangoproject.com/wiki/Version1.11Roadmap のように、ウィキのロードマップページに追加されます。

フェーズ2: 開発

リリーススケジュールの第二部は "heads-down"（真剣）作業期間と呼ばれます。フェーズ 1 の終わりに作成されたロードマップを使用し、私たちはそれに記載されている全てのタスクを完了するために非常に一生懸命働きます。

フェーズ 2 の終わりに未完成の機能は、次のリリースまで延期されます。

フェーズ 2 はアルファリリースで締めくくられます。この時点で、stable/A.B.x ブランチは main からフォークされます。

フェーズ3: バグフィックス

リリースサイクルの最終段階はバグ修正に費やされます。この時期に新機能が受け入れられることはありません。アルファ版のリリースから1ヶ月後にはベータ版を、ベータ版のリリースから1ヶ月後には リリース候補版をリリースしようと努めます。

リリース候補は文字列のフリーズを示し、最終リリースの少なくとも 2 週間前に行われます。この時点以降、新しい翻訳可能な文字列を追加してはいけません。

この段階では、マージャーはリグレッションを導入しないようにバックポートに対してより慎重になります。リリース候補の後は、リリースブロッカーとドキュメントの修正のみがバックポートされるべきです。

このフェーズと並行して、main は新しい機能を受け取ることができ、それらは A.B+1 サイクルでリリースされます。

バグフィックスリリース

フィーチャーリリース (たとえば、A.B) の後、最新のリリースはバグフィックスモードに移行します。

以前の機能リリース用のブランチ (例: stable/A.B-1.x) は、バグ修正を含みます。メインで修正された重大なバグは、バグ修正ブランチ でも 修正される必要があります。これは、コミットがバグ修正と機能追加をきれいに分離する必要があることを意味します。メインに修正をコミットする開発者は、現在のバグ修正ブランチにもその修正を適用する責任があります。