从 1.0 版本开始，Django 的发行编号如下方式工作：
\n版本编号为 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，bugfix/security 版本将从这些分支发布。
关于 Django 项目如何出于安全目的发布新版本的更多信息，请参见 我们的安全政策。
\n功能发行（A.B，A.B+1，等等）大约每 8 个月进行一次 —— 详情请见 release process 。这些发行将包含新的功能，对现有功能的改进等等。
\n补丁版本（A.B.C，A.B.C+1 等等）将根据需要发布，以修复错误和／或安全问题。
\n这些版本将与相关的功能版本 100% 兼容，除非由于安全原因或为了防止数据丢失而无法做到。因此，“我应该升级到最新的补丁版本吗？” 的答案将永远是 “是的”。
\n某些功能版本将被指定为长期支持（LTS）版本。这些版本将在保证的时间内，通常是三年内得到安全和数据丢失的修复。
\n请参见 the download page ，了解被指定为长期支持的版本。
\n从 Django 2.0 开始，版本号将使用一种松散的 语义版本 ，这样一来，LTS 之后的每个版本都将提升到下一个 “点零” 版本。例如：2.0、2.1、2.2（LTS）、3.0、3.1、3.2（LTS）等等。
\n语义版本使人们更容易一目了然地看到各版本之间的兼容情况。它还有助于预测兼容性垫片何时会被移除。这不是一个纯粹的语义版本形式，因为每个功能版本都会继续有一些记录在案的向后不兼容问题，在这些问题上不可能有一个废弃的路径，或者不值得花费。此外，在 LTS 版本（X.2）中开始的弃用将在非零版本（Y.1）中放弃，以适应我们的政策，即至少在两个功能版本中保留弃用的垫片。请继续阅读下一节，了解一个例子。
\n一个功能版本可能会废弃以前版本中的某些功能。如果一个功能在 A.x 版本中被弃用，它将继续在所有 A.x 版本中工作（对于所有版本的 x），但会引发警告。被废弃的功能将在 B.0 版本中移除，如果是在上一个 A.x 版本中废弃的功能，则在 B.1 版本中移除，以确保废弃的功能至少在两个版本中完成。
\n因此，举例来说，如果我们决定在 Django 4.2 中开始废止一个函数：
\nDjango 4.2 将包含一个向后兼容的函数副本，它将引发一个 RemovedInDjango51Warning。
Django 5.0（4.2 之后的版本）仍将包含向后兼容的副本。
Django 5.1 将直接删除该功能。
这些警告在默认情况下是静默的。你可以用 python -Wd 选项打开这些警告的显示。
一个更普遍的例子：
\nX.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 中添加的废弃垫片。
也请参见 弃用一个功能 指南。
\n在任何时候，Django 的开发者团队都会在不同程度上支持一系列的版本。请参阅下载页面的 支持的版本部分 ，了解每个版本的当前支持情况。
\n目前的开发分支 main 将获得需要少量重构的新功能和错误修复。
应用于主分支的补丁也必须应用于最后一个功能发行分支，当它们修复关键问题时，将在该功能系列的下一个补丁发行中发布：
\n安全问题。
数据丢失漏洞。
崩溃漏洞。
最新稳定发行的新功能中的主要功能漏洞。
在当前版本系列中引入的旧版本 Django 的缺陷。
经验法则是，对于那些一开始就会阻止发行的漏洞（发行障碍），修复将被向后移植到最后一个功能发行。
\n安全修复和数据丢失漏洞将被应用于当前的主分支、最后两个功能发行分支以及任何其他支持的长期支持发行分支。
一般来说，文档修复会更自由地向后移植到最后一个发行分支。这是因为让最后一个发行的文档是最新的和正确的是非常有利的，而且引入缺陷的风险也更小。
作为一个具体的例子，考虑在 Django 5.1 和 5.2 发布之间的一个时间点。在这个时间点上：
\n功能将被添加到开发主分支，作为 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 使用了一个基于时间的发行时间表，每八个月左右一次功能发行。
\nAfter each feature release, the release manager will publish a timeline for the\nnext feature release. The timeline for an upcoming feature release can be found\nin the corresponding wiki roadmap page, e.g.\nhttps://code.djangoproject.com/wiki/Version6.0Roadmap.
\nWork begins on the feature release A.B after the feature freeze of the\nprevious release, i.e. when the stable/A.B-1.x branch is forked.
You can find the current branch under active development in the\nDjango release process on Trac.
\nAll major and minor features, including deprecations and breaking changes, must\nbe merged by the feature freeze. Any features not done by this point will be\ndeferred to the next feature release.
\nAt this point, the stable/A.B.x branch will be forked from main.
After the alpha, all bug fixes merged in main are also backported to\nstable/A.B.x. Refactors are backported at the discretion of the merger.\nMergers will be more and more conservative with backports, to avoid introducing\nregressions.
In parallel to this phase, main can continue to receive new features, to be\nreleased in the A.B+1 cycle.
If there is still a consistent stream of release blockers coming in at the\nplanned release candidate date, a beta 2 will be released to encourage further\ntesting and the release candidate date will be pushed out ~1 month.
\nThe release candidate marks the string freeze, and it happens at least two\nweeks before the final release. Translators can then submit updated\ntranslations for inclusion in the final release. After this point, new\ntranslatable strings must not be added.
\nAfter the release candidate, only release blockers and documentation fixes are\nbackported.
\nIdeally, the final release will ship two weeks after the last release\ncandidate.
\nIf there are major bugs still being found 2 weeks after the release candidate,\nthere will be a decision on how to proceed (likely another release candidate\nwould be issued and the final release date will be pushed out).
\n在一个功能发行（如 A.B）后，之前的版本将进入漏洞修复模式。
\n上一个功能发行的分支（例如：stable/A.B-1.x）将包括漏洞修复。在 main 上修复的重要漏洞 也 必须在漏洞分支上修复；这意味着提交时需要将漏洞修复和功能添加干净地分开。向 main 提交修复的开发者将负责把该修复应用于当前的漏洞修复分支。