从版本1.0开始，Django的版本号如下：
在git中，每个Django版本都有一个标签，指示其版本号，并使用Django发行版签名。此外，每个版本系列都有自己的分支，称为stable/A.B.x，并且将从这些分支发出错误修复/安全版本。
有关Django项目如何针对安全性问题发布新版本的详细信息，请参阅our security policies。
主要版本（A.B，A.B + 1等）将大约每九个月发生一次 - 有关详情，请参阅下面的发布流程。这些版本将包含新功能，对现有功能的改进等。
主要版本可能会弃用以前版本的某些功能。如果某个功能在版本A.B中已弃用，它将继续在版本A.B和A.B+1中工作，但会引发警告。它将在版本A.B+2中删除。
因此，例如，如果我们决定开始在Django 1.7中弃用一个函数：
次要版本（A.B.C等）将根据需要发布，经常解决安全问题。
这些版本将与相关的主要版本100％兼容，除非出于安全原因或为了防止数据丢失，这是不可能的。所以“我应该升级到最新的小版本吗？”的答案将永远是“是”。
在任何时候，Django的开发团队将支持一系列版本到不同的级别。有关每个版本的当前支持状态，请参见下载页。
当前的开发主人将获得需要重大重构的新功能和错误修复。
应用于主分支的修补程序还必须应用于最后一个主发行版本，以便在下一个次发行版本发布时解决关键问题：
经验法则是，修复程序将被反向运行到最后一个主要版本，以防止在第一个地方（发布阻止程序）阻止发布。
安全修复和数据丢失错误将应用于当前主设备，最近两个主要版本和当前LTS release。
文档修复通常会更自由地反向到最后一个发布分支。这是因为对于最后一个发布的文档是最新的和正确的，并且引入回归的风险不是很关心，这是非常有利的。
作为一个具体的例子，考虑在发布Django 1.7和1.8之间的时间。在这个时间点：
此外，Django团队会偶尔将某些版本指定为“长期支持”（LTS）版本。LTS版本将获得安全和数据丢失修复应用一个保证的时间段，通常3年以上，无论后来的发行速度。
有关已指定用于长期支持的发行版，请参见下载页。
Django使用基于时间的发布计划，主要（即1.8，1.9，2.0等）每九个月发布一次，或更多，取决于功能。
每次发布后，经过几个星期的适当冷却期后，核心开发人员将检查该地区并宣布下一个版本的时间表。大多数发布将安排在6-9个月的范围内，但如果我们有更大的功能开发，我们可能安排更长的时间，以允许更有抱负的工作。
每个发布周期将分为三个周期，每个周期大约占周期的三分之一：
发布过程的第一阶段将专注于确定下一个版本中要包括的功能。这应该包括大量关于这些功能的初步工作 - 工作代码胜过宏伟的设计。
在第一部分的结尾，核心开发人员将为即将发布的版本提出功能列表。这将分为：
任何至少在第三个月底之前完成的工作都不能用于下一个版本；单独的设计是不够的。
发布时间表的第二个三分之一是“倒数”工作时间。使用第一阶段结束时生成的路线图，我们将非常努力地完成一切。
更长的发布计划在这个阶段可能花费三分之一以上的时间。
在第二阶段结束时，任何未完成的“可能”功能将推迟到下一版本。虽然不应该发生，任何“必须”的功能将延长第二阶段，从而推迟最终版本。
第二阶段将达到α释放。此时，stable/A.B.x分支将从master分叉。
发布周期的最后三分之一是用于修复错误 - 在此期间不会接受新功能。我们将尝试在一个月后发布测试版本，并在两个月后发布候选人。
发布候选标记字符串冻结，它发生在最终发布前至少两周。此后，不能添加新的可翻译字符串。
在这个阶段，提交者将对backports越来越保守，以避免引入回归。在发布候选人之后，应该仅反向发布版本阻止程序和文档修订。
与此阶段并行，master可以接收新功能，在A.B+1周期中释放。
在主要版本（例如A.B），以前的版本将进入错误修正模式。
前一主要版本的分支（例如stable/A.B-1.x）将包括错误修正。修复在主服务器上的关键错误必须固定在错误修正分支上；这意味着提交需要干净地将错误修复与功能添加分离。提交修复的开发人员将负责也将修复应用到当前的修正分支。
2015年5月13日