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ヶ月ごとにリリースされます。
After each feature release, the release manager will publish a timeline for the next feature release. The timeline for an upcoming feature release can be found in the corresponding wiki roadmap page, e.g. https://code.djangoproject.com/wiki/Version6.0Roadmap.
Feature release schedule and stages¶
Active development / Pre-feature freeze¶
Work begins on the feature release A.B after the feature freeze of the
previous release, i.e. when the stable/A.B-1.x branch is forked.
You can find the current branch under active development in the Django release process on Trac.
Feature freeze / Alpha release¶
All major and minor features, including deprecations and breaking changes, must be merged by the feature freeze. Any features not done by this point will be deferred to the next feature release.
At this point, the stable/A.B.x branch will be forked from main.
Non-release blocking bug fix freeze / Beta release¶
After the alpha, all bug fixes merged in main are also backported to
stable/A.B.x. Refactors are backported at the discretion of the merger.
Mergers will be more and more conservative with backports, to avoid introducing
regressions.
In parallel to this phase, main can continue to receive new features, to be
released in the A.B+1 cycle.
Translation string freeze / Release candidate release¶
If there is still a consistent stream of release blockers coming in at the planned release candidate date, a beta 2 will be released to encourage further testing and the release candidate date will be pushed out ~1 month.
The release candidate marks the string freeze, and it happens at least two weeks before the final release. Translators can then submit updated translations for inclusion in the final release. After this point, new translatable strings must not be added.
After the release candidate, only release blockers and documentation fixes are backported.
Final release¶
Ideally, the final release will ship two weeks after the last release candidate.
If there are major bugs still being found 2 weeks after the release candidate, there will be a decision on how to proceed (likely another release candidate would be issued and the final release date will be pushed out).
バグフィックスリリース¶
フィーチャーリリース (たとえば、A.B) の後、最新のリリースはバグフィックスモードに移行します。
以前の機能リリース用のブランチ (例: stable/A.B-1.x) は、バグ修正を含みます。メインで修正された重大なバグは、バグ修正ブランチ でも 修正される必要があります。これは、コミットがバグ修正と機能追加をきれいに分離する必要があることを意味します。メインに修正をコミットする開発者は、現在のバグ修正ブランチにもその修正を適用する責任があります。
