正式发布¶

从 1.0 版本开始，Django 的版本号遵循以下规则

• 版本号采用 A.B 或 A.B.C 的格式。

• A.B 是功能发布版本号。每个版本在很大程度上与前一个版本向后兼容。此规则的例外情况将在发行说明中列出。

• C 是补丁发布版本号，用于错误修复和安全发布时递增。这些版本将与之前的补丁版本 100% 向后兼容。唯一的例外是当安全或数据丢失问题无法在不破坏向后兼容性的情况下修复时。如果发生这种情况，发行说明将提供详细的升级说明。

• 在新的功能发布之前，我们将进行 alpha、beta 和候选发布。它们的格式为 A.B alpha/beta/rc N，这意味着版本 A.B 的第 N 个 alpha/beta/候选版本。

在 Git 中，每个 Django 发布版本都将有一个指示其版本号的标签，并使用 Django 发布密钥进行签名。此外，每个发布系列都有自己的分支，称为 stable/A.B.x，错误修复/安全发布将从这些分支发布。

有关 Django 项目如何出于安全目的发布新版本的更多信息，请参阅 我们的安全策略。

功能发布¶

功能发布（A.B、A.B+1 等）大约每八个月发布一次 - 有关详细信息，请参阅 发布流程。这些版本将包含新功能、对现有功能的改进等。

补丁发布¶

补丁发布（A.B.C、A.B.C+1 等）将根据需要发布，以修复错误和/或安全问题。

这些版本将与关联的功能发布 100% 兼容，除非出于安全原因或防止数据丢失而无法做到这一点。因此，对于“我是否应该升级到最新的补丁版本？”的答案始终是“是”。

长期支持版本¶

某些功能版本将被指定为长期支持 (LTS) 版本。这些版本将在一段保证的时间内（通常为三年）获得安全和数据丢失修复。

请参阅 下载页面 以了解哪些版本被指定为长期支持版本。

发布节奏¶

从 Django 2.0 开始，版本号将使用 语义版本控制 的一种宽松形式，以便每个 LTS 之后的版本都将升级到下一个“点零”版本。例如：2.0、2.1、2.2（LTS）、3.0、3.1、3.2（LTS）等。

SemVer 使您可以更轻松地一目了然地了解版本之间的兼容性。它还有助于预测兼容性垫片何时会被移除。它不是 SemVer 的纯形式，因为每个功能版本都将继续存在一些记录在案的向后不兼容性（在这些情况下，弃用路径是不可能的或不值得的成本）。此外，在 LTS 版本 (X.2) 中开始的弃用将在非点零版本 (Y.1) 中删除，以适应我们至少保持两个功能版本弃用垫片的策略。请继续阅读下一节以了解示例。

弃用策略¶

功能发布可能会弃用先前版本中的某些功能。如果某个功能在功能发布 A.x 中被弃用，它将继续在所有 A.x 版本（所有 x 版本）中工作，但会发出警告。弃用的功能将在 B.0 版本中删除，或者对于在最后一个 A.x 功能版本中弃用的功能将在 B.1 版本中删除，以确保弃用至少跨越 2 个功能版本完成。

例如，如果我们决定在 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，但第三方应用程序需要保持与 X.2 LTS 的兼容性，以简化 LTS 到 LTS 的升级）。

• Z.0：删除在 Y.0 和 Y.1 中添加的弃用垫片。

另请参阅 弃用功能 指南。

支持的版本¶

在任何时间点，Django 的开发团队都将支持一系列版本，并提供不同级别的支持。请参阅下载页面 支持的版本部分 以了解每个版本的当前支持状态。

• 当前开发分支 main 将获得需要非平凡重构的新功能和错误修复。

• 应用于 main 分支的补丁也必须应用于最后一个功能发布分支，以便在修复严重问题时在该功能系列的下一个补丁版本中发布

  • 安全问题。

  • 数据丢失错误。

  • 崩溃错误。

  • 最新稳定版本中新功能的主要功能错误。

  • 在当前发布系列中引入的来自旧版 Django 的回归。

  经验法则是，将修复程序回传到最后一个功能发布版本，以解决本来会阻止发布的错误（发布阻止程序）。

• 安全修复和数据丢失错误将应用于当前的 main 分支、最后两个功能发布分支以及任何其他受支持的长期支持发布分支。

• 文档修复通常会更自由地回传到最后一个发布分支。这是因为使最后一个版本的文档保持最新和正确非常有利，并且引入回归的风险要小得多。

举一个具体的例子，考虑 Django 5.1 和 5.2 发布之间的时间点。在这一点上

• 功能将添加到开发 main 分支，并作为 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 使用基于时间的时间表发布，大约每八个月发布一次功能版本。

在每次功能发布后，发布经理将宣布下一个功能发布的时间表。