バージョン 1.0 以降から、Django のリリース番号は以下の規則に従って付けられています。
\nバージョン番号は、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 と呼ばれ、バグフィックスやセキュリティのリリースは、このブランチから作られます。
For more information about how the Django project issues new releases for\nsecurity purposes, please see our security policies.
\nフィーチャーリリース (A.B、A.B+1 など) は、だいたい8ヶ月ごとに公開されます。詳しくは release process を読んでください。このリリースには、新機能や既存の機能への改良などが含まれます。
\nパッチリリース (A.B.C、A.B.C+1 など) は必要に応じて公開されます。このリリースでは、バグフィックスやセキュリティ問題へのパッチが含まれます。
\nこのリリースでは、セキュリティ問題の解決やデータの損失を避けられない例外的な場合を除いて、対応するフィーチャーリリースとの 100% 後方互換性が保証されています。そのため、「最新のパッチリリースは更新するべきでしょうか？」という質問に対する答えは、常に「はい」です。
\n特定のフィーチャーリリースは、長期サポート (long-term support; LTS) リリースに指定されます。このリリースは、通常3年間の保証期間内であれば、セキュリティ問題とデータ損失問題へのパッチが適用されることになっています。
\n長期保証に指定されたリリースを確認するには、the download page を見てください。
\nDjango 2.0 から、緩い形で セマンティックバージョニング を採用します。LTSの次のバージョンは必ず、".0" に上げられます。例えば、 2.0, 2.1, 2.2 (LTS), 3.0, 3.1, 3.2 (LTS), という具合です。
\nSemVer を使用すると、リリースの互換性が一目でわかりやすくなります。また、互換性のシムがいつ削除されるかを予測するのにも役立ちます。これは、各機能リリースが引き続き、非推奨のパスが可能でないか、またはコストに見合わない場合に限り、いくつかのドキュメント化された後方互換性のない変更を持ち続けるため、純粋な形の SemVer ではありません。また、LTS リリース (X.2) で開始された非推奨は、少なくとも2つの機能リリースの間、非推奨のシムを保持するという私たちのポリシーに対応するため、非ドットゼロリリース (Y.1) で削除されます。次のセクションに進んで、例を読んでください。
\n新しいフィーチャーリリースでは、過去のリリースにある特定の機能が非推奨になることがあります。過去のフィーチャーリリース A.x のある機能が新しいフィーチャーリリースで非推奨になった場合、すべての A.x のバージョン (x の全バージョンに対して) では、それまで通りに機能し続けますが、警告が出るようになります。非推奨になった機能は、バージョン B.0 のリリースで削除されます。ただし、機能の非推奨が A.x の最後のフィーチャーリリースで行われた場合に限り、最低でも2つのフィーチャーリリースで非推奨期間が続いた後に、バージョン B.1 のリリースで削除されます。
\nしたがって、たとえば、Django 4.2 である機能を非推奨にすることを決定した場合、その機能は次のような過程をたどることになります。
\nDjango 4.2 には後方互換性のある機能のレプリカが含まれ、RemovedInDjango51Warning が発生します。
Django 5.0（4.2 の次のバージョン）は、後方互換性のあるレプリカを引き続き含んでいます。
Django 5.1 では、この機能が完全に除外されます。
警告はデフォルトで表示されません。これらの警告の表示を有効にするには、python -Wd オプションを使用します。
より一般的な例では、次のようになります。
\nX.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 ガイドも参照してください。
\nDjango の開発チームは、常時さまざまなレベルでリリースセットへのサポートを提供しています。詳しくは、ダウンロードページの サポートバージョンのセクション にある、各バージョンに対する現在のサポート状況のリストを見てください。
\n現在の開発ブランチ main は、大規模なリファクタリングを必要とする新機能とバグ修正を受け取ります。
メインブランチに適用されたパッチは、重大な問題を修正する場合に限り、それが属する機能リリースシリーズの最新フィーチャーリリースブランチにも適用され、次のパッチリリースでリリースされなければなりません:
\nセキュリティ上の問題。
データ損失のバグ。
クラッシュのバグ。
最新の安定版リリースの新機能における主要な機能バグ。
現在のリリースシリーズで以前のバージョンの Django から導入されたリグレッション。
一般的な原則として、リリースを最初から阻止する可能性があったバグ (リリースブロッカー) に対する修正は、最後の機能リリースにバックポートされます。
\nセキュリティ修正とデータ損失のバグは、現在のメインブランチ、最後の2つの機能リリースブランチ、およびその他のサポートされている長期サポートリリースブランチに適用されます。
ドキュメントの修正は、一般的に最後のリリースブランチにもっと自由にバックポートされます。それは、最新リリースのドキュメントが最新かつ正確であることが非常に有利であり、リグレッションを導入するリスクがそれほど心配されないためです。
具体的な例として、Django 5.1 と 5.2 のリリースの中間点にある時点を考えてみましょう。この時点で:
\n新機能は開発のメインブランチに追加され、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ヶ月ごとにリリースされます。
\nAfter each feature release, the release manager will publish a timeline for the\nnext feature release. The timeline for an upcoming feature release can be found\nin the corresponding wiki roadmap page, e.g.\nhttps://code.djangoproject.com/wiki/Version6.0Roadmap.
\nWork begins on the feature release A.B after the feature freeze of the\nprevious release, i.e. when the stable/A.B-1.x branch is forked.
You can find the current branch under active development in the\nDjango release process on Trac.
\nAll major and minor features, including deprecations and breaking changes, must\nbe merged by the feature freeze. Any features not done by this point will be\ndeferred to the next feature release.
\nAt this point, the stable/A.B.x branch will be forked from main.
After the alpha, all bug fixes merged in main are also backported to\nstable/A.B.x. Refactors are backported at the discretion of the merger.\nMergers will be more and more conservative with backports, to avoid introducing\nregressions.
In parallel to this phase, main can continue to receive new features, to be\nreleased in the A.B+1 cycle.
If there is still a consistent stream of release blockers coming in at the\nplanned release candidate date, a beta 2 will be released to encourage further\ntesting and the release candidate date will be pushed out ~1 month.
\nThe release candidate marks the string freeze, and it happens at least two\nweeks before the final release. Translators can then submit updated\ntranslations for inclusion in the final release. After this point, new\ntranslatable strings must not be added.
\nAfter the release candidate, only release blockers and documentation fixes are\nbackported.
\nIdeally, the final release will ship two weeks after the last release\ncandidate.
\nIf there are major bugs still being found 2 weeks after the release candidate,\nthere will be a decision on how to proceed (likely another release candidate\nwould be issued and the final release date will be pushed out).
\nフィーチャーリリース (たとえば、A.B) の後、最新のリリースはバグフィックスモードに移行します。
\n以前の機能リリース用のブランチ (例: stable/A.B-1.x) は、バグ修正を含みます。メインで修正された重大なバグは、バグ修正ブランチ でも 修正される必要があります。これは、コミットがバグ修正と機能追加をきれいに分離する必要があることを意味します。メインに修正をコミットする開発者は、現在のバグ修正ブランチにもその修正を適用する責任があります。