从 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 使用了一个基于时间的发行时间表，每八个月左右一次功能发行。
\n每次功能发行后，发行经理都会宣布下一次功能发行的时间表。
\n每个发行周期由三部分组成：
\n发行过程的第一阶段将包括确定在下一个版本中包括哪些主要功能。这应该包括对这些功能进行大量的初步工作 —— 工作代码胜过宏伟设计。
\n即将发布的版本的主要功能将被添加到 wiki 路线图页面，例如： https://code.djangoproject.com/wiki/Version1.11Roadmap。
\n发行时间表的第二部分是 “低头” 工作期。利用第一阶段结束时产生的路线图，我们都将非常努力地工作，以完成上面的所有工作。
\n在第二阶段结束时，任何未完成的功能将被推迟到下一个版本。
\n第二阶段将以 alpha 版本达到高潮。此时，stable/A.B.x 分支将从 main 分叉出来。
发行周期的最后一部分是用来修复错误的 —— 在这段时间内不会接受新的功能。我们将尝试在 alpha 版的一个月后发行 beta 版，在 beta 版一个月后发行候选版。
\n候选发行版本标志着字符串冻结，它至少发生在最终发行版本的两周前。在这之后，不得再添加新的可翻译字符串。
\n在这个阶段，合并者将会更加保守地进行回溯，以避免引入回归问题。在发布候选版之后，只应该回溯关于发布阻塞问题和文档修复的变更。
\n在这个阶段的同时，main 可以接受新的功能，在 A.B+1 周期内发布。
在一个功能发行（如 A.B）后，之前的版本将进入漏洞修复模式。
\n上一个功能发行的分支（例如：stable/A.B-1.x）将包括漏洞修复。在 main 上修复的重要漏洞 也 必须在漏洞分支上修复；这意味着提交时需要将漏洞修复和功能添加干净地分开。向 main 提交修复的开发者将负责把该修复应用于当前的漏洞修复分支。