Django 的发布流程 — Django 文档
Django的发布流程
正式发行
从 1.0 版开始，Django 的发布编号工作如下：
- 版本以
A.B或A.B.C的形式编号。 A.B是 功能发布 版本号。 每个版本都将主要向后兼容以前的版本。 此规则的例外情况将在发行说明中列出。C是 补丁发布 版本号，它会随着错误修复和安全发布而增加。 这些版本将 100% 向后兼容之前的补丁版本。 唯一的例外是在不破坏向后兼容性的情况下无法修复安全或数据丢失问题。 如果发生这种情况，发行说明将提供详细的升级说明。- 在新功能发布之前，我们将发布 alpha、beta 和候选发布版本。 它们的形式为
A.B alpha/beta/rc N，这意味着Nthalpha/beta/版本A.B的候选发布版本。
在 git 中，每个 Django 版本都会有一个标记来指示其版本号，并使用 Django 版本密钥进行签名。 此外，每个版本系列都有自己的分支，称为 stable/A.B.x，并且将从这些分支发布错误修复/安全版本。
有关 Django 项目如何出于安全目的发布新版本的更多信息，请参阅 我们的安全策略 。
- 功能发行
功能发布（AB、A.B+1 等）大约每八个月发布一次——详情参见 发布流程 。 这些版本将包含新功能、对现有功能的改进等。
- 补丁发行
补丁版本（A.B.C，A.B.C+1 等等）将根据需要发布，以修复错误和／或安全问题。
这些版本将与相关功能版本 100% c 兼容，除非出于安全原因或防止数据丢失而无法实现。 所以“我应该升级到最新的补丁版本吗？”的答案将永远是“是”。
- 长期支持发行
某些功能版本将被指定为长期支持 (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) 中删除，以适应我们为至少两个功能版本保留弃用垫片的政策。 继续阅读下一节以获取示例。
废弃政策
功能版本可能会弃用先前版本中的某些功能。 如果某个功能在功能版本 Ax 中被弃用，它将继续在所有 Ax 版本中工作（对于 x 的所有版本），但会引发警告。 不推荐使用的功能将在 B.0 版本中删除，或者 B.1 中删除在最后一个 Ax 功能版本中不推荐使用的功能，以确保不推荐使用至少在 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`` 将获得需要少量重构的新功能和错误修复。
应用于主分支的补丁也必须应用于最后一个功能发行分支，当它们修复关键问题时，将在该功能系列的下一个补丁发行中发布：
安全问题。
数据丢失漏洞。
崩溃漏洞。
最新稳定发行的新功能中的主要功能漏洞。
来自旧版本 Django 的回归。
经验法则是，对于那些一开始就会阻止发行的漏洞（发行障碍），修复将被向后移植到最后一个功能发行。
安全修复和数据丢失漏洞将被应用于当前的主分支、最后两个功能发行分支以及任何其他支持的长期支持发行分支。
文档修复通常会更自由地向后移植到最后一个发布分支。 这是因为让最新版本的文档保持最新和正确是非常有利的，并且引入回归的风险要小得多。
作为一个具体的例子，考虑一下 Django 5.1 和 5.2 发布之间的中间时刻。 此时：
- 功能将被添加到开发主分支，作为 Django 5.2 发行。
- 关键错误修复将应用于
stable/5.1.x分支，并作为 5.1.1、5.1.2 等发布。 - 针对数据丢失问题的安全修复和错误修复将应用于
master和stable/5.1.x、stable/5.0.x和stable/4.2.x(LTS) 分支。 它们会触发5.1.1、5.0.5、4.2.8等的释放。 - 文档修复将应用于 master，如果容易向后移植，将应用于最新的稳定分支
5.1.x。
发行过程
Django 使用了一个基于时间的发行时间表，每八个月左右一次功能发行。
每次功能发行后，发行经理都会宣布下一次功能发行的时间表。
发行周期
每个发行周期由三部分组成：
第一阶段：功能建议
发布过程的第一阶段将包括确定下一个版本要包含哪些主要功能。 这应该包括对这些功能的大量初步工作——工作代码胜过宏伟的设计。
即将发布的主要功能将添加到 wiki 路线图页面，例如 https://code.djangoproject.com/wiki/Version1.11Roadmap。
第二阶段：开发
发布时间表的第二部分是“低头”工作期。 使用第一阶段结束时制定的路线图，我们都将非常努力地完成所有工作。
在第二阶段结束时，任何未完成的功能将被推迟到下一个版本。
第二阶段将在 alpha 版本中达到高潮。 此时，stable/A.B.x 分支将从 master 分叉出来。
第三阶段：修复漏洞
发布周期的最后一部分用于修复错误——在此期间不会接受任何新功能。 我们将尝试在 Alpha 版发布一个月后发布 Beta 版，并在 Beta 版发布一个月后发布候选版。
候选发布标志着字符串冻结，它发生在最终发布前至少两周。 在此之后，不得添加新的可翻译字符串。
在这个阶段，提交者对反向移植会越来越保守，以避免引入回归。 在候选发布之后，只应向后移植发布阻止程序和文档修复程序。
与此阶段并行，master 可以接收新功能，将在 A.B+1 周期中发布。
漏洞修复发行
在功能发布之后（例如 AB)，之前的版本将进入错误修复模式。
上一个功能版本的分支（例如 stable/A.B-1.x) 将包括错误修正。 master 上修复的严重错误必须 也 修复在错误修复分支上； 这意味着提交需要将错误修复与功能添加完全分开。 向 master 提交修复的开发人员将负责将修复应用到当前的 bugfix 分支。
