Django路线图

作者：Tim Graham 发布于 2015年6月25日

在收到超过3000份针对Django开发者社区调查的回复以及在django-developers邮件列表上进行的长时间讨论之后，Django团队采用了以下发布计划（如有需要，可能会发生变化）。

计划是每8个月发布一个新功能版本，每2年发布一个新的长期支持版本（LTS）。LTS版本将获得3年的安全更新支持。

版本系列 发布日期 主流支持结束1 扩展支持结束2
1.9 2015年12月2016年8月 2017年4月
1.10 2016年8月2017年4月 2017年12月
1.11 LTS2017年4月2017年12月 至少到2020年4月
2.0 2017年12月2018年8月 2019年4月
此表格的最新版本可在下载页面找到。

[1] 安全修复、数据丢失错误、崩溃错误、新引入功能中的主要功能错误以及来自旧版Django的回归。
[2] 安全修复和数据丢失错误。

社区对12个月和6个月的发布计划意见不一，我们认为8个月是一个很好的折衷方案。它也使发布日期在每2年发布一个新LTS方面很好地对齐。

如我们的支持版本策略中所述，每个功能版本的（包括安全修复、数据丢失错误、崩溃错误、新引入功能中的主要功能错误以及来自旧版Django的回归）主流支持将持续到下一个功能版本发布（8个月，除非延迟）。扩展支持（包括安全修复和数据丢失错误）将持续到下一个功能版本（另外8个月，除非延迟）。

团队还决定调整我们的弃用策略，以便简化从一个LTS升级到下一个LTS的过程，并允许第三方应用程序更轻松地支持当前支持的Django版本。我们观察到，大多数第三方应用程序直到下一个LTS（1.8）发布之前，才考虑放弃对先前LTS（1.4）的支持。这意味着所有这些项目一旦想要添加对Django 1.6+的支持，就必须实现自己的兼容性垫片（而不是使用Django的），因为Django 1.4中弃用功能的兼容性垫片已被删除。这导致了包含大量条件版本分支的丑陋代码。

新策略应该使使用最新LTS版本开发应用程序变得容易，并且可以使其在无需进行大量更改的情况下继续工作，直到下一个LTS。按照此计划，如果您从1.8开始，那么您就已经在LTS上了。如果您从1.9开始，则应该有一条简单的升级路径一直到1.11，这将是一个LTS版本。此外，如果您在1.8上运行时不使用任何弃用功能，那么从LTS升级到LTS（1.8到1.11）应该足够简单。

为了反映我们对以简化第三方应用程序维护和从一个LTS版本升级到下一个LTS版本的方式支持兼容性垫片的新承诺，我们将从Django 2.0开始采用语义版本控制的松散形式。SemVer使您能够一目了然地了解版本之间的兼容性。它还有助于预测何时将删除兼容性垫片。它不是SemVer的纯形式，因为每个8个月的功能版本都将继续包含一些记录在案的向后不兼容性，在这些情况下，弃用路径是不可能的或不值得的。此外，每个LTS版本的弃用将在非点零版本中删除，以适应我们至少保留2个版本的弃用垫片的策略。

以下是Django中弃用功能何时将被删除的概述

未来版本：3.0、3.1、3.2（LTS）、4.0等。

在Django 1.11之后，版本将升级到Django 2.0。之后，每个LTS之后的版本将升级到下一个“点零”版本。LTS版本将始终为“X.2”，因此第三方应用程序可以将支持目标设置为X.2到X+1.2。我们没有将Django 1.9升级到2.0，因为Django 1.9已经在文档和弃用警告中进行了预期，因此这样的更改可能会造成比其价值更大的混淆。django.utils.deprecation.RemovedInDjango20Warning在Django 1.8中将重命名为RemovedInDjango110Warning在下一个补丁版本（1.8.3）中，并且文档已更新以反映这些更改。

最后提醒一下，Django 1.11可能是最后一个支持Python 2.7的版本，因为它将得到支持，直到2020年Python 2上游支持结束。我们采用了以下Python版本支持策略

我们将支持一个Python版本，直到且包括第一个Django LTS版本，该版本的安全支持在该Python版本的安全性支持结束之后结束。例如，Python 3.3的安全支持于2017年9月结束，而Django 1.8 LTS的安全支持于2018年4月结束。因此，Django 1.8是最后一个支持Python 3.3的版本。

常见问题解答和投诉

问：基于时间的发布是否会影响版本的稳定性？为什么不在一切准备就绪时发布？

答：版本稳定性将继续成为我们的首要任务。如果存在重大未解决的问题，则会延迟发布（从而延长对旧版本的支持）。部分归功于Django奖学金计划提供的资源，Django 1.8是按计划发布的。

投诉：停止破坏向后兼容性。由于缺乏对用户的尊重，全世界浪费了大量时间和金钱。

答：团队非常重视向后兼容性。有时，为了持续改进Django，必须进行此类更改。您可以通过测试和提供预发布版本的反馈来帮助我们保持诚实。如果您重视稳定性而不是新功能，那么新的弃用策略应该使您更容易仅使用LTS版本并减少升级频率。

投诉：很高兴看到功能快速推出，但有一个问题：我开始看到第三方软件包难以跟上并支持LTS软件包。

答：希望上面概述的新弃用策略将有助于解决此问题。

问：为什么文档/发行说明中不包含从过去两三个版本移植（例如，将LTS升级到LTS）的升级指南/清单？

答：当您决定将LTS升级到LTS时，团队建议一次升级一个Django版本。我们认为我们无法提供官方的LTS到LTS升级指南（维护一个指南工作量过大，并且主要涉及复制所有中间版本的发行说明）。但是，新的弃用策略将使LTS到LTS的升级更容易，因为它不需要处理任何API删除（只要您的代码在旧的LTS版本上不会触发任何弃用警告）。

投诉：如果LTS版本之间有更多重叠，那就太好了。现在，在发布新的LTS之前，旧的LTS有6个月的时间被淘汰。这对我们这样的产品公司来说非常困难，因为我们必须比这6个月长得多地维护对先前版本的支持。

答：新计划提供了1年的LTS支持重叠。

投诉：3年根本不是LTS，在企业界，LTS意味着10年。我希望有一个非常稳定的Django核心，它只在安全问题和重要的修复程序上更新，并且至少支持5年。

答：除了Django奖学金获得者之外，团队完全由志愿者组成，时间有限。我们中的一些人在大型企业工作，因此我们了解这些挑战。我们认为，如果您需要超过3年的支持，则应考虑聘请付费承包商来修补Django安装中的安全问题（与组织为Python提供类似支持的方式相同）。

问：我是一个可复用应用程序的维护者。我应该支持哪些 Django 版本？

答：我们建议您支持 Django 团队支持的相同 Django 版本。根据新的弃用策略，应该可以支持两个连续的 LTS 版本（例如 1.8 和 1.11）以及介于两者之间的所有非 LTS 版本，而无需在您自己的代码中使用向后兼容性垫片，只要您的代码在较低的 LTS 版本（1.8）上运行时没有警告即可，因为保证任何一个 LTS 版本中的非弃用功能将在下一个 LTS 版本中保留。

返回顶部