Django的发布过程

正式发布

自1.0版以来,Django的版本编号工作如下:

  • 版本在表单中编号 A.BA.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 对于每个版本的当前支持状态的下载页。

  • 当前的开发主管将获得新的特性和需要非平凡重构的错误修复。

  • 应用于主分支的补丁也必须应用于最后一个功能发布分支,在该功能系列的下一个补丁发布中发布,当它们修复关键问题时:

    • 安全问题。
    • 数据丢失错误。
    • 崩溃的错误。
    • 最新稳定版本的新功能中存在主要功能缺陷。
    • 老版本的Django的回归。

    经验法则是,修复程序将被反向移植到最后一个功能版本中,以解决最初阻止发布的bug(发布拦截器)。

  • 安全修复和数据丢失错误将应用于当前的主版本、最后两个功能发布分支以及任何其他受支持的长期支持发布分支。

  • 文档修复通常会更自由地返回到最后一个发行版分支。这是因为拥有最新和正确的最新版本的文档是非常有利的,引入回归的风险也就不那么令人担心了。

作为一个具体的例子,考虑一下django 5.1和5.2发布之间的一段时间。此时此刻:

  • 特性将被添加到开发大师中,作为django 5.2发布。
  • 关键错误修复将应用于 stable/5.1.x 分支,发布为5.1.1、5.1.2等。
  • 数据丢失问题的安全修复和错误修复将应用于 master 以及对 stable/5.1.xstable/5.0.xstable/4.2.x (LTS)分支。它们会触发释放 5.1.15.0.54.2.8 等。
  • 文档修复将应用于master,如果很容易进行反向移植,则应用于最新的稳定分支, 5.1.x .

释放过程

Django使用基于时间的发布时间表,每八个月左右发布一次特性。

在每个特性发布之后,发布管理器将宣布下一个特性发布的时间表。

释放周期

每个发布周期由三部分组成:

第一阶段:功能建议

发布过程的第一个阶段将包括确定在下一个版本中要包含哪些主要特性。这应该包括对这些特性的大量前期工作——工作代码胜过总体设计。

即将发布的版本的主要功能将添加到wiki路线图页面,例如https://code.djangoproject.com/wiki/version1.11路线图。

第二阶段:开发

发布计划的第二部分是“提前”工作期。使用第一阶段结束时制定的路线图,我们都将非常努力地完成上面的所有工作。

在第二阶段结束时,任何未完成的特性都将被推迟到下一个版本。

第二阶段将以alpha释放结束。在这一点上, stable/A.B.x 分支将从 master .

第三阶段:错误修复

发布周期的最后一部分是修复bug——在此期间不会接受任何新特性。我们将尝试在alpha发布一个月后发布beta版本,在beta发布一个月后发布候选版本。

发布候选标记字符串冻结,并且至少在最终发布前两周发生。在此之后,不能添加新的可翻译字符串。

在这个阶段,提交者将越来越保守地使用反向端口,以避免引入回归。在候选版本发布之后,只应该对发布拦截器和文档修复进行反向移植。

与这个阶段平行, master 可以接收新功能,将在 A.B+1 周期。

错误修复版本

功能发布后(例如A.B),上一个版本将进入错误修复模式。

上一个功能版本的分支(例如 stable/A.B-1.x )将包括错误修复。在主服务器上修复的关键错误必须 also 在bugfix分支上进行修复;这意味着提交需要将bug修复与功能添加完全分离。向master提交修复的开发人员还将负责将修复应用到当前的bugfix分支。