我想我应该在Wim的答案所倡导的策略中添加一点内容-首先让Django的适当版本同时在2.7和3.x上运行-并概述一些对我有效的策略。在
Python2.7是你的逃生舱,直到你触发3.x你的测试应该在这两种情况下运行
不要使用任何3.x特定的功能,比如f字符串
首先是python3.x,然后是Django 2.x,它不运行在2.7上
尽早开始,不要过度分析,但要避免大爆炸的方法
一开始一个文件一个文件。在
从您拥有测试套件的最低级别代码开始,例如实用程序库。在
如果可能的话,试着逐渐地将您的更改合并到2.7生产分支中,并使您的3.x移植代码与prod更改保持同步。在
从哪个次要版本的Django开始?
我的标准是Django迁移可以相当复杂(实际上需要更多的思考,而不是2=>;3个工作)。因此,我将转到最新和最好的1.11版本,这样你已经为你的2.7用户提供了一些价值。在1.11版上可能有很多2.x版之前的兼容性垫片,你会得到它的2.x弃用警告。在
从python3.x的哪个次要版本开始?
最好从各个角度考虑,例如第三方libs的可用性、CI/devops套件的支持以及所选服务器操作系统映像的可用性。您可以一直安装3.8并尝试对要求.txt例如,它本身。在
利用git(或您使用的任何scm)和virtualenv分开requirement.txt文件,但是。。。在
如果您有一个基于文件的git repo,那么可以用pip install -e 将每个venv指向同一个代码行。这意味着,在两个不同的终端中,可以针对相同的unittest运行2.7和