Django的更新策略

Official releases

从版本1.0开始,Django的版本号如下:

  • 版本以A.BA.B.C的形式编号。
  • A.B功能版本版本号。 每个版本将主要向后兼容以前的版本。 此规则的例外将在发行说明中列出。
  • C补丁版本版本号,增加了bugvix和安全版本。 这些版本将与以前的补丁版本100%向后兼容。 唯一的例外是当安全或数据丢失问题不能解决而不破坏向后兼容性。 如果发生这种情况,发行说明将提供详细的升级说明。
  • 在新功能发布之前,我们将制作alpha,beta和发布候选版本。 These are of the form A.B alpha/beta/rc N, which means the Nth alpha/beta/release candidate of version A.B.

在git中,每个Django版本都有一个标签,指示其版本号,并使用Django发行版签名。 此外,每个版本系列都有自己的分支,称为stable/A.B.x,并且将从这些分支发出错误修复/安全版本。

有关Django项目如何针对安全性问题发布新版本的详细信息,请参阅our security policies

Feature release
功能版本(A.B,A.B + 1等) 大概每八个月会发生一次 - 详见发布流程 这些版本将包含新功能,对现有功能的改进等。
Patch release

补丁版本(A.B.C,A.B.C + 1等) 将根据需要发布,以修复错误和/或安全问题。

这些版本将与相关的功能版本100%兼容,除非这是不可能的安全原因或防止数据丢失。 那么“我应该升级到最新的补丁版本”的答案将永远是“是的”。

Long-term support release

某些功能版本将被指定为长期支持(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)的形式被删除,以适应我们对至少两个功能版本保留弃用垫片的策略。 请阅读下一节的例子。

弃用政策

功能版本可能会废弃以前版本中的某些功能。 如果在功能版本A.x中不推荐使用功能,它将继续在所有A.x版本(适用于所有版本的x)中工作,但会引发警告。 B.0版本中将删除不推荐使用的功能,或者在最后一次A.x功能版本中不推荐使用B.1版本的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中添加删除弃用垫片。

Supported versions

在任何时候,Django的开发团队将支持一系列版本到不同的级别。 有关每个版本的当前支持状态,请参阅下载页面的支持的版本部分

  • 当前的开发大师将获得需要非平凡重构的新功能和错误修复。

  • 应用于主分支的补丁还必须应用于上一个功能发布分支,以便在该功能系列的下一个补丁版本中解决关键问题时发布:

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

    经验法则是修复程序将返回到最后一个功能版本,以防止首次发布(发行版阻止程序)的错误。

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

  • 文档修复通常会更自由地反向到最后一个发布分支。 这是因为对于最后一个发布的文档是最新的和正确的,并且引入回归的风险不是很关心,这是非常有利的。

作为一个具体的例子,考虑Django 5.1和5.2之间的一段时间。 在这个时间点:

  • 功能将被添加到开发大师,作为Django 5.2发布。
  • 重要的错误修复将应用于stable/5.1.x分支,并以5.1.1,5.1.2等方式发布。
  • 数据丢失问题的安全修补程序和错误修复将适用于masterstable/5.1.xstable/5.0.x,和stable/4.2.x(LTS)分支。 它们将触发5.1.15.0.54.2.8等的释放。
  • 文档修正将被应用于master,并且如果容易地被反向输入到最新的稳定分支5.1.x

Release process

Django使用基于时间的发布时间表,功能发布每八个月左右。

每个功能发布后,发行经理将宣布下一个功能版本的时间表。

Release cycle

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

Phase one: feature proposal

发布过程的第一阶段将包括确定下一个版本中要包含哪些主要功能。 这应该包括大量关于这些功能的初步工作 - 工作代码胜过宏伟的设计。

即将发布的主要功能将被添加到维基路线图页面,例如 https://code.djangoproject.com/wiki/Version1.11Roadmap T0>。

Phase two: development

发布时间表的第二部分是“头脑”的工作时间。 使用第一阶段结束时生成的路线图,我们将非常努力地完成一切。

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

第二阶段将达到α释放。 此时,stable/A.B.x分支将从master分叉。

Phase three: bugfixes

发布周期的最后一部分是修复错误 - 在此期间不会接受新功能。 我们将尝试在Alpha之后一个月发布测试版,并在beta之后一个月发布一个候选版本。

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

在这个阶段,提交者将对backports越来越保守,以避免引入回归。 在发布候选人之后,应该仅反向发布版本阻止程序和文档修订。

与此阶段并行,master可以接收新功能,在A.B+1周期中释放。

Bug-fix releases

在功能发布(例如A.B)之后,以前的版本将进入错误修复模式。

上一个功能版本的分支(例如stable/A.B-1.x)将包括错误修复。 修复在主服务器上的关键错误必须固定在错误修正分支上;这意味着提交需要干净地将错误修复与功能添加分离。 提交修复的开发人员将负责也将修复应用到当前的修正分支。