バージョン 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.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 makes it easier to see at a glance how compatible releases are with each other. It also helps to anticipate when compatibility shims will be removed. It's not a pure form of SemVer as each feature release will continue to have a few documented backwards incompatibilities where a deprecation path isn't possible or not worth the cost. Also, deprecations started in an LTS release (X.2) will be dropped in a non-dot-zero release (Y.1) to accommodate our policy of keeping deprecation shims for at least two feature releases. Read on to the next section for an example.
新しいフィーチャーリリースでは、過去のリリースにある特定の機能が非推奨になることがあります。過去のフィーチャーリリース A.x のある機能が新しいフィーチャーリリースで非推奨になった場合、すべての A.x のバージョン (x の全バージョンに対して) では、それまで通りに機能し続けますが、警告が出るようになります。非推奨になった機能は、バージョン B.0 のリリースで削除されます。ただし、機能の非推奨が A.x の最後のフィーチャーリリースで行われた場合に限り、最低でも2つのフィーチャーリリースで非推奨期間が続いた後に、バージョン B.1 のリリースで削除されます。
したがって、たとえば、Django 4.2 である機能を非推奨にすることを決定した場合、その機能は次のような過程をたどることになります。
RemovedInDjango51Warning.The warnings are silent by default. You can turn on display of these warnings
with the python -Wd option.
より一般的な例では、次のようになります。
See also the Deprecating a feature guide.
Django の開発チームは、常時さまざまなレベルでリリースセットへのサポートを提供しています。詳しくは、ダウンロードページの サポートバージョンのセクション にある、各バージョンに対する現在のサポート状況のリストを見てください。
The current development branch main will get new features and bug fixes
requiring non-trivial refactoring.
Patches applied to the main branch must also be applied to the last feature release branch, to be released in the next patch release of that feature series, when they fix critical problems:
The rule of thumb is that fixes will be backported to the last feature release for bugs that would have prevented a release in the first place (release blockers).
Security fixes and data loss bugs will be applied to the current main branch, the last two feature release branches, and any other supported long-term support release branches.
Documentation fixes generally will be more freely backported to the last release branch. That's because it's highly advantageous to have the docs for the last release be up-to-date and correct, and the risk of introducing regressions is much less of a concern.
As a concrete example, consider a moment in time halfway between the release of Django 5.1 and 5.2. At this point in time:
stable/5.1.x branch, and
released as 5.1.1, 5.1.2, etc.main and to the stable/5.1.x, stable/5.0.x, and
stable/4.2.x (LTS) branches. They will trigger the release of 5.1.1,
5.0.5, 4.2.8, etc.5.1.x.Django は期間に基づいたスケジュールを採用しています。フィーチャーリリースは約8ヶ月ごとにリリースされます。
それぞれのフィーチャーリリースの公開後、リリースマネージャは次のフィーチャーリリースのスケジュールを告知します。
それぞれのリリースサイクルは、以下の3つのパートからなります。
The first phase of the release process will include figuring out what major features to include in the next version. This should include a good deal of preliminary work on those features -- working code trumps grand design.
Major features for an upcoming release will be added to the wiki roadmap page, e.g. https://code.djangoproject.com/wiki/Version1.11Roadmap.
The second part of the release schedule is the "heads-down" working period. Using the roadmap produced at the end of phase one, we'll all work very hard to get everything on it done.
At the end of phase two, any unfinished features will be postponed until the next release.
Phase two will culminate with an alpha release. At this point, the
stable/A.B.x branch will be forked from main.
The last part of a release cycle is spent fixing bugs -- no new features will be accepted during this time. We'll try to release a beta release one month after the alpha and a release candidate one month after the beta.
The release candidate marks the string freeze, and it happens at least two weeks before the final release. After this point, new translatable strings must not be added.
During this phase, mergers will be more and more conservative with backports, to avoid introducing regressions. After the release candidate, only release blockers and documentation fixes should be backported.
In parallel to this phase, main can receive new features, to be released
in the A.B+1 cycle.
フィーチャーリリース (たとえば、A.B) の後、最新のリリースはバグフィックスモードに移行します。
The branch for the previous feature release (e.g. stable/A.B-1.x) will
include bugfixes. Critical bugs fixed on main must also be fixed on the
bugfix branch; this means that commits need to cleanly separate bug fixes from
feature additions. The developer who commits a fix to main will be
responsible for also applying the fix to the current bugfix branch.
2022年6月01日