Skip to main content

Django的发布过程

官方发布

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

  • 版本以 A.BA.B.C 的形式编号。

  • A.B功能发布 版本号。每个版本将主要向后兼容以前的版本。此规则的例外将在发行说明中列出。

  • C补丁释放 版本号,随着bug修复和安全版本增加。这些发行版将100%向后兼容以前的补丁版本。唯一的例外是当不能解决安全或数据丢失问题而不破坏向后兼容性。如果发生这种情况,发行说明将提供详细的升级说明。

  • 在新功能发布之前,我们将制作alpha版,beta版和发布候选版本。这些是 A.B alpha/beta/rc N 的形式,这意味着版本 A.BNth alpha/beta/release候选。

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

有关Django项目如何为安全目的发布新版本的详细信息,请参阅 我们的安全政策

功能发布

功能版本(A.B,A.B + 1等)将大约每八个月发生一次 - 有关详细信息,请参阅 release process。这些版本将包含新功能,对现有功能的改进等。

补丁释放

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

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

长期支持释放

某些功能版本将被指定为长期支持(LTS)版本。这些版本将获得在保证的一段时间(通常为三年)内应用的安全和数据丢失修复。

有关已指定用于长期支持的版本,请参阅 the download page

释放节奏

从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,以确保在至少两个功能版本中完成弃用。

因此,例如,如果我们决定开始在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的开发团队将支持一系列不同级别的发布。有关每个版本的当前支持状态,请参阅下载页面的 支持的版本部分

  • 当前的开发主控将获得需要进行不重要的重构的新功能和错误修复。

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

    • 安全问题。

    • 数据丢失错误。

    • 崩溃的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.xstable/4.2.x (LTS)分支。它们将触发 5.1.15.0.54.2.8 等的释放。

  • 文档修复将应用于主机,并且如果轻松地反向运行,则应用于最新的稳定分支 5.1.x

发布过程

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

每个功能发布后,发布管理器将公布下一个功能发布的时间轴。

发布周期

每个发布周期包括三个部分:

第一阶段:功能建议

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

即将发布的主要功能将添加到Wiki路线图页面,例如。 https://code.djangoproject.com/wiki/Version1.9Roadmap

第二阶段:发展

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

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

第二阶段将达到α释放。在这一点上,stable/A.B.x 分支将从 master 分支。

第三阶段:错误修正

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

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

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

与此阶段并行,master 可以接收新特性,在 A.B+1 周期中发布。

Bug修复版本

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

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