Django的更新策略

Official releases

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

  • 版本以A.BA.B.C的形式编号。
  • A.B主版本号码。每个版本将主要向后兼容以前的版本。此规则的例外将在发行说明中列出。B == 9时,下一个主要版本将是A+1.0例如,Django 2.0将遵循Django 1.9。对“零点”发行没有什么特别的。
  • C次要版本号,它会针对错误和安全修复程序增加。新的次要版本将与之前的次要版本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

主要发行

主要版本(A.B,A.B + 1等)将大约每九个月发生一次 - 有关详情,请参阅下面的发布流程这些版本将包含新功能,对现有功能的改进等。

主要版本可能会弃用以前版本的某些功能。如果某个功能在版本A.B中已弃用,它将继续在版本A.BA.B+1中工作,但会引发警告。它将在版本A.B+2中删除。

因此,例如,如果我们决定开始在Django 1.7中弃用一个函数:

  • Django 1.7将包含一个向后兼容的函数的副本,将产生RemovedInDjango19Warning默认情况下,此警告是静默的;您可以使用Python的-Wd选项打开这些警告的显示。
  • Django 1.8仍然包含向后兼容的副本。此警告默认情况下会变为响亮,并且可能会很恼人。
  • Django 1.9将彻底删除该功能。
次要版本

次要版本(A.B.C等)将根据需要发布,经常解决安全问题。

这些版本将与相关的主要版本100%兼容,除非出于安全原因或为了防止数据丢失,这是不可能的。所以“我应该升级到最新的小版本吗?”的答案将永远是“是”。

Supported versions

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

  • 当前的开发主人将获得需要重大重构的新功能和错误修复。

  • 应用于主分支的修补程序还必须应用于最后一个主发行版本,以便在下一个次发行版本发布时解决关键问题:

    • 安全问题。
    • 数据丢失错误。
    • 崩溃的bug。
    • 新引入的功能中的主要功能错误。

    经验法则是,修复程序将被反向运行到最后一个主要版本,以防止在第一个地方(发布阻止程序)阻止发布。

  • 安全修复和数据丢失错误将应用于当前主设备,最近两个主要版本和当前LTS release

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

作为一个具体的例子,考虑在发布Django 1.7和1.8之间的时间。在这个时间点:

  • 特性将被添加到开发主控,将作为Django 1.8发布。
  • 关键错误修复将应用于stable/1.7.x分支,并释放为1.7.1,1.7.2等。
  • 针对数据丢失问题的安全修复程序和错误修复将应用于masterstable/1.7.xstable/1.6.xstable/1.4.x(LTS)分支。它们将触发1.7.11.6.11.4.1等的发布。
  • 文档修订将应用于主机,如果轻松地反向运行,则应用于1.7.x1.6.x分支。

Long-term support (LTS) releases

此外,Django团队会偶尔将某些版本指定为“长期支持”(LTS)版本。LTS版本将获得安全和数据丢失修复应用一个保证的时间段,通常3年以上,无论后来的发行速度。

有关已指定用于长期支持的发行版,请参见下载页

Release process

Django使用基于时间的发布计划,主要(即1.8,1.9,2.0等)每九个月发布一次,或更多,取决于功能。

每次发布后,经过几个星期的适当冷却期后,核心开发人员将检查该地区并宣布下一个版本的时间表。大多数发布将安排在6-9个月的范围内,但如果我们有更大的功能开发,我们可能安排更长的时间,以允许更有抱负的工作。

Release cycle

每个发布周期将分为三个周期,每个周期大约占周期的三分之一:

Phase one: feature proposal

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

在第一部分的结尾,核心开发人员将为即将发布的版本提出功能列表。这将分为:

  • “必须”:如果没有完成,将延迟释放的关键功能
  • “也许”功能:如果没有完成,将推送到下一个版本
  • “不会发生”:明确推迟到更高版本的功能。

任何至少在第三个月底之前完成的工作都不能用于下一个版本;单独的设计是不够的。

Phase two: development

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

更长的发布计划在这个阶段可能花费三分之一以上的时间。

在第二阶段结束时,任何未完成的“可能”功能将推迟到下一版本。虽然不应该发生,任何“必须”的功能将延长第二阶段,从而推迟最终版本。

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

Phase three: bugfixes

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

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

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

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

Bug-fix releases

在主要版本(例如A.B),以前的版本将进入错误修正模式。

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