自1.0版以来，Django的版本编号工作如下：
版本在表单中编号 A.B 或 A.B.C .
A.B 是 特征释放 版本号。每个版本将主要向后兼容上一个版本。此规则的例外情况将在发行说明中列出。
C 是 补片释放 版本号，为错误修复和安全性发布而递增。这些版本将与以前的补丁版本100%向后兼容。唯一的例外是，在不破坏向后兼容性的情况下，无法修复安全或数据丢失问题。如果发生这种情况，发行说明将提供详细的升级说明。
在新特性发布之前，我们将发布alpha、beta和候选版本。这些是这样的 A.B alpha/beta/rc N 也就是说 Nth alpha/beta/版本候选版本 A.B .
在Git中，每个django版本都有一个标记，指示其版本号，并用django发行密钥签名。此外，每个发布系列都有自己的分支，称为 stable/A.B.x 将从这些分支机构发出错误修复/安全性发布。
有关django项目如何为安全目的发布新版本的更多信息，请参见 our security policies .
特性发布（A.B、A.B+1等）大约每八个月发布一次--请参见 release process 详情。这些版本将包含新功能、对现有功能的改进，等等。
补丁发布（A.B.C、A.B.C+1等）将根据需要发布，以修复错误和/或安全问题。
这些版本将与相关的功能版本100%兼容，除非出于安全原因或为了防止数据丢失这是不可能的。所以回答“我应该升级到最新补丁版本吗？”将始终为“是”。
某些功能版本将被指定为长期支持（LTS）版本。这些版本将在保证的一段时间内（通常为三年）得到安全和数据丢失修复。
见 the download page 用于指定长期支持的版本。
从Django 2.0开始，版本号将使用松散形式的 semantic versioning 这样，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的开发团队都将支持一组不同级别的版本。见 the supported versions section 对于每个版本的当前支持状态的下载页。
当前的发展部门 main 将获得需要大量重构的新功能和错误修复。
在修复关键问题时，应用于主分支的补丁程序还必须应用于将在该功能系列的下一个补丁程序版本中发布的最后一个功能发布分支：
安全问题。
数据丢失错误。
崩溃的错误。
最新稳定版本的新功能中存在主要功能缺陷。
从当前版本系列中引入的Django旧版本的回归。
经验法则是，修复程序将被反向移植到最后一个功能版本中，以解决最初阻止发布的bug（发布拦截器）。
安全修复和数据丢失错误将应用于当前的主分支、最后两个功能发布分支以及任何其他受支持的长期支持发布分支。
文档修复通常会更自由地返回到最后一个发行版分支。这是因为拥有最新和正确的最新版本的文档是非常有利的，引入回归的风险也就不那么令人担心了。
作为一个具体的例子，考虑一下django 5.1和5.2发布之间的一段时间。此时此刻：
特性将被添加到开发主分支中，将作为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使用基于时间的发布时间表，每八个月左右发布一次特性。
在每个特性发布之后，发布管理器将宣布下一个特性发布的时间表。
每个发布周期由三部分组成：
发布过程的第一个阶段将包括确定在下一个版本中要包含哪些主要特性。这应该包括对这些特性的大量前期工作——工作代码胜过总体设计。
即将发布的版本的主要功能将添加到wiki路线图页面，例如https://code.djangoproject.com/wiki/version1.11路线图。
发布计划的第二部分是“提前”工作期。使用第一阶段结束时制定的路线图，我们都将非常努力地完成上面的所有工作。
在第二阶段结束时，任何未完成的特性都将被推迟到下一个版本。
第二阶段将在Alpha版本中达到顶峰。此时， stable/A.B.x 分支将从 main 。
发布周期的最后一部分是修复bug——在此期间不会接受任何新特性。我们将尝试在alpha发布一个月后发布beta版本，在beta发布一个月后发布候选版本。
发布候选标记字符串冻结，并且至少在最终发布前两周发生。在此之后，不能添加新的可翻译字符串。
在这一阶段，合并将对后端越来越保守，以避免引入倒退。在发布候选版本之后，应该只向后移植版本拦截器和文档修复。
与此阶段并行的是， main 可以接收新功能，将在 A.B+1 周而复始。
功能发布后（例如A.B），上一个版本将进入错误修复模式。
先前功能版本的分支(例如 stable/A.B-1.x )将包括错误修复。Main上修复的关键错误必须 also 在错误修复分支上进行修复；这意味着提交需要清楚地将错误修复与功能添加分开。向Main提交修复程序的开发人员将负责将该修复程序应用于当前的错误修复分支。
12月 18, 2023