在开始一个新的Django项目时，你需要做的第一件事就是选择你要使用的Django版本。在任何时候，可能有多达三个支持的Django版本可供选择。
- 以前的长期支持版本（LTS）
- 当前的LTS
- 最新的官方版本
我把预发布版排除在这个列表之外，预发布版只应该用于测试。
你在为什么而优化？
要问自己的第一个问题是你在为什么而优化。当我们为客户构建应用程序时，我们几乎总是在优化以降低成本，无论是在最初的开发过程中还是在推出后的支持中。出于这个原因，我们选择的版本要满足最大限度地提高与Django生态系统的互操作性，并最大限度地减少后期的维护（也就是劳作）。除非你是在做一个业余项目，想玩玩新功能，否则我认为这些目标是普遍的。
关于Django版本管理的说明
Django并没有严格遵循语义版本标准。版本总是由三个数字组成(major.minor.patch)。小版本2 ，总是LTS版本。在LTS之后，主版本会被递增，并在此基础上发布两个次版本(x.0 和x.1)。补丁版本是针对在任何支持的版本上发现的错误发布的。更多信息，见DEP-0004。
最大限度地减少维护
最小化未来维护的最好方法是选择LTS版本。在长达三年的时间里不必进行重大版本升级的承诺意味着更少的升级周期和更少的维护工作。
最大限度地提高互操作性
构建一个不依赖其他开源Django库的Django应用程序是非常罕见的。遇到一个非常适合你的项目的库，却发现它与Django的版本不兼容，这将减缓你的进度。作为一个优秀的开源社区成员，提交一个补丁是正确的，但这需要时间和精力，否则就可以花在你的应用程序上。
开源项目通常是由志愿者维护的，他们在空闲时间工作，没有报酬。因此，支持可能会滞后于Django的官方发布。 如果你在一个新的LTS版本发布后不久就开始开发，那么使用之前的LTS可能更有意义，因为它应该有广泛的应用，而且还有接近9个月的支持期。如果你采取这种方式，请仔细阅读新的LTS发布说明，以便为你的项目跳转到下一个LTS做好未来准备。在所有情况下，确保你的代码在运行时没有任何废弃警告。
避免跳到一个全新的LTS的另一个原因是为了避免在测试中没有发现的任何错误。我一般喜欢等到第一个补丁发布时再采用新的LTS版本（4.2.1 ，而不是4.2.0 ）。这些补丁通常在最初发布的一个月后出现，并包含在野外发现的错误修复。
例外情况
就像所有的编码经验法则一样，也有例外，但要避免陷入 "它是新的和闪亮的 "陷阱中。如果一个较新的Django版本有一个对你的应用程序很重要的功能，这可能是一个暂时跳过LTS的好理由。这方面的一个例子是Django 1.9中引入了对Postgres的本地JSON支持。
如果你使用最小的依赖，或者知道你所有的依赖都支持一个新的LTS版本，这可能是一个很好的理由来开始使用最近发布的LTS。然而，这种方法很容易使自己陷入困境。当你的项目开始运作时，你可能会发现你确实需要一个你开始时没有想到的库。
最后，如果你的开发是作为一种爱好，或者是为了学习新的东西，那就使用你想要的任何版本吧不是每个开发项目都需要由成本或对企业最有利的东西来决定的。
**Tldr;**使用最新的LTS，它至少已经收到一个补丁版本。版本号的格式是x.2.z ，其中z > 0 。这通常不是你可以从PyPI下载的最新版本。
