Djangoのリリースプロセス
公式リリース
バージョン1.0以降、Djangoのリリース番号は次のように機能します。
- バージョンには、
A.BまたはA.B.Cの形式で番号が付けられています。 A.Bは、機能リリースのバージョン番号です。 各バージョンは、以前のリリースとほとんど下位互換性があります。 このルールの例外は、リリースノートに記載されています。Cは、パッチリリースのバージョン番号であり、バグ修正およびセキュリティリリースのために増分されます。 これらのリリースは、以前のパッチリリースと100％下位互換性があります。 唯一の例外は、下位互換性を損なうことなくセキュリティまたはデータ損失の問題を修正できない場合です。 これが発生した場合、リリースノートに詳細なアップグレード手順が記載されています。- 新機能のリリース前に、アルファ版、ベータ版、リリース候補のリリースを作成します。 これらは
A.B alpha/beta/rc Nの形式であり、バージョンA.BのNthアルファ/ベータ/リリース候補を意味します。
gitでは、各Djangoリリースには、Djangoリリースキーで署名されたバージョン番号を示すタグがあります。 さらに、各リリースシリーズにはstable/A.B.xと呼ばれる独自のブランチがあり、バグ修正/セキュリティリリースはそれらのブランチから発行されます。
Djangoプロジェクトがセキュリティ目的で新しいリリースを発行する方法の詳細については、セキュリティポリシーを参照してください。
- 機能リリース
機能のリリース（AB、A.B + 1など）は約8か月ごとに行われます。詳細については、リリースプロセスを参照してください。 これらのリリースには、新機能、既存の機能の改善などが含まれます。
- パッチリリース
バグやセキュリティの問題を修正するために、必要に応じてパッチリリース（ABC、ABC + 1など）が発行されます。
これらのリリースは、セキュリティ上の理由またはデータの損失を防ぐために不可能でない限り、関連する機能リリースと100 % c互換性があります。 したがって、「最新のパッチリリースにアップグレードする必要がありますか？」に対する答えです。 常に「はい」になります。
- ロングタームサポートリリース
特定の機能リリースは、ロングタームサポート（LTS）リリースとして指定されます。 これらのリリースでは、セキュリティとデータ損失の修正が保証された期間（通常は3年間）適用されます。
長期サポート用に指定されたリリースについては、ダウンロードページを参照してください。
リリースケイデンス
Django 2.0以降、バージョン番号は緩い形式のセマンティックバージョニングを使用するため、LTSに続く各バージョンは次の「ドットゼロ」バージョンにバンプされます。 例：2.0、2.1、2.2（LTS）、3.0、3.1、3.2（LTS）など。
SemVerを使用すると、リリースの互換性を一目で簡単に確認できます。 また、互換性シムがいつ削除されるかを予測するのにも役立ちます。 これはSemVerの純粋な形式ではありません。各機能リリースには、非推奨のパスが不可能であるか、コストに見合わない場合に、いくつかの後方互換性が文書化されたままになるためです。 また、LTSリリース（X.2）で開始された非推奨は、ドットゼロ以外のリリース（Y.1）で削除され、少なくとも2つの機能リリースで非推奨シムを維持するというポリシーに対応します。 例については、次のセクションをお読みください。
非推奨ポリシー
機能リリースでは、以前のリリースの特定の機能が廃止される場合があります。 機能が機能リリースAxで非推奨になった場合、その機能はすべてのAxバージョン（xのすべてのバージョン）で引き続き機能しますが、警告が表示されます。 非推奨の機能は、B.0リリースで削除されるか、最後のAxe機能リリースで非推奨になった機能の場合はB.1で削除され、少なくとも2つの機能リリースで非推奨が行われるようになります。
したがって、たとえば、Django4.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に追加された廃止予定のシムを削除します。
機能の廃止ガイドも参照してください。
サポートされているバージョン
Djangoの開発者チームはいつでも、さまざまなレベルの一連のリリースをサポートします。 各バージョンの現在のサポート状況については、ダウンロードページのサポートされているバージョンのセクションを参照してください。
現在の開発ブランチ
mainは、重要なリファクタリングを必要とする新機能とバグ修正を取得します。メインブランチに適用されたパッチは、最後の機能リリースブランチにも適用され、重大な問題が修正されたときに、その機能シリーズの次のパッチリリースでリリースされる必要があります。
セキュリティ上の問題。
データ損失のバグ。
クラッシュするバグ。
最新の安定リリースの新機能の主な機能バグ。
現在のリリースシリーズで導入された古いバージョンのDjangoからの回帰。
経験則では、修正は、そもそもリリースを妨げていたであろうバグ（リリースブロッカー）の最後の機能リリースにバックポートされます。
セキュリティ修正とデータ損失のバグは、現在のメインブランチ、最後の2つの機能リリースブランチ、およびその他のサポートされている長期サポートリリースブランチに適用されます。
ドキュメントの修正は通常、最後のリリースブランチにより自由にバックポートされます。 これは、最後のリリースのドキュメントを最新かつ正確にすることが非常に有利であり、リグレッションが発生するリスクがはるかに少ないためです。
具体的な例として、Django5.1と5.2のリリースの中間の瞬間を考えてみましょう。 この時点で：
- 機能は開発メインブランチに追加され、Django5.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などのリリースがトリガーされます。 - ドキュメントの修正はメインに適用され、簡単にバックポートされる場合は、最新の安定したブランチ
5.1.xに適用されます。
リリースプロセス
Djangoは時間ベースのリリーススケジュールを使用しており、機能は8か月ごとにリリースされます。
各機能のリリース後、リリースマネージャーは次の機能リリースのタイムラインを発表します。
リリースサイクル
各リリースサイクルは、次の3つの部分で構成されています。
フェーズ1：機能の提案
リリースプロセスの最初のフェーズには、次のバージョンに含める主要な機能を理解することが含まれます。 これには、これらの機能に関する多くの予備作業が含まれている必要があります。作業コードは、壮大な設計よりも優れています。
今後のリリースの主な機能は、wikiロードマップページに追加されます。 https://code.djangoproject.com/wiki/Version1.11Roadmap。
フェーズ2：開発
リリーススケジュールの2番目の部分は、「ヘッドダウン」作業期間です。 フェーズ1の終わりに作成されたロードマップを使用して、すべてを完了するために全員が非常に懸命に取り組みます。
フェーズ2の終わりに、未完成の機能は次のリリースまで延期されます。
フェーズ2は、アルファリリースで最高潮に達します。 この時点で、stable/A.B.xブランチはmainから分岐します。
フェーズ3：バグ修正
リリースサイクルの最後の部分はバグの修正に費やされます–この期間中は新しい機能は受け入れられません。 アルファ版の1か月後にベータ版リリースをリリースし、ベータ版の1か月後にリリース候補をリリースしようとします。
リリース候補は文字列のフリーズをマークし、最終リリースの少なくとも2週間前に発生します。 この時点以降、新しい翻訳可能な文字列を追加しないでください。
このフェーズでは、コミッターはバックポートに対してますます保守的になり、リグレッションの発生を回避します。 リリース候補の後、リリースブロッカーとドキュメントの修正のみをバックポートする必要があります。
このフェーズと並行して、mainは、A.B+1サイクルでリリースされる新しい機能を受け取ることができます。
バグ修正リリース
機能リリース後（例： AB）、以前のリリースはバグ修正モードになります。
以前の機能リリースのブランチ（例： stable/A.B-1.x）にはバグ修正が含まれます。 mainで修正された重大なバグは、バグ修正ブランチでまた修正する必要があります。 これは、コミットがバグ修正と機能追加を明確に分離する必要があることを意味します。 mainに修正をコミットする開発者は、現在のバグ修正ブランチにも修正を適用する責任があります。
