Django のリリースプロセス

公式リリース

バージョン 1.0 以降から、Django のリリース番号は以下の規則に従って付けられています。

  • バージョン番号は、A.B または A.B.C の形式で表される。
  • A.Bフィーチャーリリース 版の番号です。大抵の場合、それぞれのバージョンで、前回のリリースとの後方互換性が保たれます。
  • C は、パッチリリース のバージョン番号で、バグフィックスとセキュリティリリースが追加されるたびに数字が1つ増えます。このリリースでは、前回のパッチリリースに対して 100% の後方互換性が保証されています。唯一の例外は、セキュリティやデータの喪失の問題によって、後方互換性を修正するために後方互換性を破らざるをえない場合のみです。このようなことが怒った場合には、パッチリリースが出された場合には、リリースノート内に更新の詳細な手順が書かれます。
  • 新しいフィーチャーリリースの前に、アルファ、ベータ、およびリリース候補版が作られます。これらのリリースのバージョン番号は A.B alpha/beta/rc N の形式で表され、バージョン A.BN番目の アルファ/ベータ/リリース候補版であることを意味します。

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 を見てください。

リリース周期

Starting with Django 2.0, version numbers will use a loose form of semantic versioning such that each version following an LTS will bump to the next "dot zero" version. For example: 2.0, 2.1, 2.2 (LTS), 3.0, 3.1, 3.2 (LTS), etc.

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 である機能を非推奨にすることを決定した場合、その機能は次のような過程をたどることになります。

  • Django 4.2 will contain a backwards-compatible replica of the function which will raise a RemovedInDjango51Warning.
  • Django 5.0 (the version that follows 4.2) will still contain the backwards-compatible replica.
  • Django 5.1 では、この機能が完全に除外されます。

The warnings are silent by default. You can turn on display of these warnings with the python -Wd option.

より一般的な例では、次のようになります。

  • X.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, third-party apps need to maintain compatibility back to X.2 LTS to ease LTS to LTS upgrades).
  • Z.0: Drop deprecation shims added in Y.0 and Y.1.

サポートバージョン

Django の開発チームは、常時さまざまなレベルでリリースセットへのサポートを提供しています。詳しくは、ダウンロードページの サポートバージョンのセクション にある、各バージョンに対する現在のサポート状況のリストを見てください。

  • 現在の開発マスターでは、新機能とある程度のリファクタリングが必要なバグフィックスが含まれたバージョンが取得できます。

  • マスターブランチに対して適用されるパッチは、最後のフィーチャーリリースのブランチにも必ず同時に適用されます。もしその修正が以下に挙げるような致命的な問題を修正していた場合は、その一連のフィーチャーリリースの次のパッチリリースとして必ずリリースされます。

    • セキュリティ上の問題。
    • データ損失のバグ。
    • キャッシュのバグ。
    • Major functionality bugs in new features of the latest stable release.
    • Regressions from older versions of Django.

    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 master, 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:

  • Features 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 released as 5.1.1, 5.1.2, etc.
  • Security fixes and bug fixes for data loss issues will be applied to master 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.
  • Documentation fixes will be applied to master, and, if easily backported, to the latest stable branch, 5.1.x.

リリースプロセス

Django は期間に基づいたスケジュールを採用しています。フィーチャーリリースは約8ヶ月ごとにリリースされます。

それぞれのフィーチャーリリースの公開後、リリースマネージャは次のフィーチャーリリースのスケジュールを告知します。

リリースサイクル

それぞれのリリースサイクルは、以下の3つのパートからなります。

フェーズ1: 機能の提案

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.

フェーズ2: 開発

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 master.

フェーズ3: バグフィックス

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, committers 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, master 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 master 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 master will be responsible for also applying the fix to the current bugfix branch.

Back to Top