バージョン 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 と呼ばれ、バグフィックスやセキュリティのリリースは、このブランチから作られます。
Django プロジェクトでセキュリティ対策の新しいリリースを公開する方法について詳しく知りたければ、Django のセキュリティポリシー を読んでください。
\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 makes it easier to see at a glance how compatible releases are with each\nother. It also helps to anticipate when compatibility shims will be removed.\nIt's not a pure form of SemVer as each feature release will continue to have a\nfew documented backwards incompatibilities where a deprecation path isn't\npossible or not worth the cost. Also, deprecations started in an LTS release\n(X.2) will be dropped in a non-dot-zero release (Y.1) to accommodate our policy\nof keeping deprecation shims for at least two feature releases. Read on to the\nnext section for an example.
\n新しいフィーチャーリリースでは、過去のリリースにある特定の機能が非推奨になることがあります。過去のフィーチャーリリース A.x のある機能が新しいフィーチャーリリースで非推奨になった場合、すべての A.x のバージョン (x の全バージョンに対して) では、それまで通りに機能し続けますが、警告が出るようになります。非推奨になった機能は、バージョン B.0 のリリースで削除されます。ただし、機能の非推奨が A.x の最後のフィーチャーリリースで行われた場合に限り、最低でも2つのフィーチャーリリースで非推奨期間が続いた後に、バージョン B.1 のリリースで削除されます。
\nしたがって、たとえば、Django 4.2 である機能を非推奨にすることを決定した場合、その機能は次のような過程をたどることになります。
\nDjango 4.2 will contain a backwards-compatible replica of the function which\nwill raise a RemovedInDjango51Warning.
Django 5.0 (the version that follows 4.2) will still contain the\nbackwards-compatible replica.
Django 5.1 では、この機能が完全に除外されます。
The warnings are silent by default. You can turn on display of these warnings\nwith the python -Wd option.
より一般的な例では、次のようになります。
\nX.0
X.1
X.2 LTS
Y.0: Drop deprecation shims added in X.0 and X.1.
Y.1: Drop deprecation shims added in X.2.
Y.2 LTS: No deprecation shims dropped (while Y.0 is no longer supported,\nthird-party apps need to maintain compatibility back to X.2 LTS to ease\nLTS to LTS upgrades).
Z.0: Drop deprecation shims added in Y.0 and Y.1.
See also the Deprecating a feature guide.
\nDjango の開発チームは、常時さまざまなレベルでリリースセットへのサポートを提供しています。詳しくは、ダウンロードページの サポートバージョンのセクション にある、各バージョンに対する現在のサポート状況のリストを見てください。
\n現在の開発マスターでは、新機能とある程度のリファクタリングが必要なバグフィックスが含まれたバージョンが取得できます。
マスターブランチに対して適用されるパッチは、最後のフィーチャーリリースのブランチにも必ず同時に適用されます。もしその修正が以下に挙げるような致命的な問題を修正していた場合は、その一連のフィーチャーリリースの次のパッチリリースとして必ずリリースされます。
\nセキュリティ上の問題。
データ損失のバグ。
クラッシュのバグ。
Major functionality bugs in new features of the latest stable release.
Regressions from older versions of Django introduced in the current release\nseries.
The rule of thumb is that fixes will be backported to the last feature\nrelease for bugs that would have prevented a release in the first place\n(release blockers).
\nSecurity fixes and data loss bugs will be applied to the current master, the\nlast two feature release branches, and any other supported long-term\nsupport release branches.
Documentation fixes generally will be more freely backported to the last\nrelease branch. That's because it's highly advantageous to have the docs for\nthe last release be up-to-date and correct, and the risk of introducing\nregressions is much less of a concern.
As a concrete example, consider a moment in time halfway between the release of\nDjango 5.1 and 5.2. At this point in time:
\nFeatures will be added to development master, to be released as Django 5.2.
Critical bug fixes will be applied to the stable/5.1.x branch, and\nreleased as 5.1.1, 5.1.2, etc.
Security fixes and bug fixes for data loss issues will be applied to\nmaster and to the stable/5.1.x, stable/5.0.x, and\nstable/4.2.x (LTS) branches. They will trigger the release of 5.1.1,\n5.0.5, 4.2.8, etc.
Documentation fixes will be applied to master, and, if easily backported, to\nthe latest stable branch, 5.1.x.
Django は期間に基づいたスケジュールを採用しています。フィーチャーリリースは約8ヶ月ごとにリリースされます。
\nそれぞれのフィーチャーリリースの公開後、リリースマネージャは次のフィーチャーリリースのスケジュールを告知します。
\nそれぞれのリリースサイクルは、以下の3つのパートからなります。
\nThe first phase of the release process will include figuring out what major\nfeatures to include in the next version. This should include a good deal of\npreliminary work on those features -- working code trumps grand design.
\nMajor features for an upcoming release will be added to the wiki roadmap page,\ne.g. https://code.djangoproject.com/wiki/Version1.11Roadmap.
\nThe second part of the release schedule is the "heads-down" working period.\nUsing the roadmap produced at the end of phase one, we'll all work very hard to\nget everything on it done.
\nAt the end of phase two, any unfinished features will be postponed until the\nnext release.
\nPhase two will culminate with an alpha release. At this point, the\nstable/A.B.x branch will be forked from master.
The last part of a release cycle is spent fixing bugs -- no new features will\nbe accepted during this time. We'll try to release a beta release one month\nafter the alpha and a release candidate one month after the beta.
\nThe release candidate marks the string freeze, and it happens at least two\nweeks before the final release. After this point, new translatable strings\nmust not be added.
\nDuring this phase, committers will be more and more conservative with\nbackports, to avoid introducing regressions. After the release candidate, only\nrelease blockers and documentation fixes should be backported.
\nIn parallel to this phase, master can receive new features, to be released\nin the A.B+1 cycle.
フィーチャーリリース (たとえば、A.B) の後、最新のリリースはバグフィックスモードに移行します。
\nThe branch for the previous feature release (e.g. stable/A.B-1.x) will\ninclude bugfixes. Critical bugs fixed on master must also be fixed on the\nbugfix branch; this means that commits need to cleanly separate bug fixes from\nfeature additions. The developer who commits a fix to master will be\nresponsible for also applying the fix to the current bugfix branch.