Django的发布过程

官方发布

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

  • 版本以A.BA.B.C的形式编号。
  • A.B is the feature release version number. 每个版本将大多向后兼容以前的版本。 此规则的例外情况将在发行说明中列出。
  • C is the patch release version number, which is incremented for bugfix and security releases. 这些版本将与以前的补丁版本向后兼容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,并且将从这些分支发布bugfix / security发行版。

有关Django项目如何为安全目的而发布新版本的更多信息,请参阅our security policies

Feature release
功能版本(A.B,A.B + 1等)大概每8个月发生一次 - 详情请参阅发布过程 这些版本将包含新功能,对现有功能的改进等。
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版本中不再使用已弃用的功能,或B.1中最近一次使用的A.x功能版本中不推荐使用的功能,以确保弃用功能至少在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的开发团队都会支持一系列不同级别的发布。 有关每个版本的当前支持状态,请参见下载页面的支持的版本部分

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

  • 应用于主分支的修补程序还必须应用到最后一个功能部件发行版分支,以便在修复关键问题时在该功能部件系列的下一个修补程序版本中发布:

    • 安全问题。
    • 数据丢失错误。
    • 崩溃的错误。
    • 主要功能错误在最新的稳定版本的新功能。
    • 旧版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.xstable/4.2.x(LTS)分支。 它们将触发5.1.15.0.54.2.8等的发布。
  • 文档修复将应用于master,并且如果轻松地向后移动到最新的stable分支,5.1.x

发布过程

Django使用基于时间的发布计划,每八个月发布一次功能。

在每个功能发布之后,发布管理器将宣布下一个功能发布的时间线。

发布周期

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

第一阶段:功能提案

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

即将发行的版本的主要特征将被添加到wiki路线图页面,例如, https://code.djangoproject.com/wiki/Version1.11Roadmap T0>。

第二阶段:开发

发布时间表的第二部分是“低头”工作期。 使用第一阶段结束时制定的路线图,我们都会非常努力地完成所有工作。

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

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

第三阶段:bug修正

花了一个发布周期的最后一部分来修复bug,在这段时间内不会接受任何新功能。 我们将尝试在测试版发布一个月之后的alpha版本和发布候选版本一个月后发布beta版本。

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

在这个阶段,为了避免引入回归,提交者将会越来越保守。 发布候选版本后,只有发布阻止程序和文档修复应该被回溯。

In parallel to this phase, master can receive new features, to be released in the A.B+1 cycle.

Bug修复版本

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

之前版本的分支(例如stable/A.B-1.x)将包含错误修正。 在master上修复的重要bug也必须在bugfix分支上固定这意味着提交需要干净地从功能添加中分离错误修复。 提交修订的开发人员将负责将修复应用到当前的bugfix分支。