Django 1.8升级至1.11+ LTS：分步升级还是直接升级？

Hey there! As someone who's walked through multiple Django version upgrades (including from 1.8 to 1.11), let me share my take on your question and break down what makes the most sense for you—especially since this is your first time tackling a cross-version upgrade.

Which approach is better? #

Step-by-step upgrade (1.8 → 1.9 → 1.10 → 1.11) #

This is hands down the safer and more manageable option for someone new to Django upgrades. Here's why:

• Each version jump has a smaller set of breaking changes and deprecations to handle. Instead of drowning in a flood of errors from 3 versions worth of changes, you'll only deal with the specific tweaks needed for one version at a time.
• Django gives you clear deprecation warnings in each intermediate version that point exactly what needs fixing before moving to the next. For example, when you upgrade to 1.9, you'll see warnings about APIs that will be removed in 1.10—fixing these early prevents hard errors later.
• The official upgrade guides for each minor version are concise and focused, making it easier to digest and apply the necessary changes without feeling overwhelmed.

Direct upgrade from 1.8 to 1.11 #

While this might seem faster on paper, it's extremely risky, especially for non-trivial projects. Here's the catch:

• You'll face a massive pile of breaking changes all at once. For example, Django 1.9 removed django.core.context_processors, 1.10 replaced the old url() function with path()/re_path(), and 1.11 tightened up ORM behavior—trying to untangle which change caused which error is a nightmare.
• Third-party dependencies are another big issue. Many packages that worked with 1.8 might not support 1.11 directly, and you won't have intermediate versions to test compatibility step-by-step.

My recommended step-by-step workflow #

Follow these steps for each version jump (1.8→1.9, then 1.9→1.10, then 1.10→1.11):

1. Create a dedicated Git branch for each upgrade. This way, if something breaks, you can easily roll back without messing up your main codebase.
2. Check third-party compatibility first. Before upgrading Django, make sure all your installed packages (like DRF, Celery, or custom admin extensions) have versions that support the target Django version. Use pip check to catch dependency conflicts early.
3. Upgrade Django to the target minor version:

   pip install django==1.9.13  # Use the latest patch version for stability
   

4. Run Django's built-in check tool:

   python manage.py check
   

   This will flag most compatibility issues—like deprecated settings, removed APIs, or invalid configurations—with clear messages. Fix these first.
5. Test core functionality by running your server (python manage.py runserver) and going through key parts of your app. Pay close attention to console warnings—don't ignore them, as they'll turn into errors in the next version.
6. Run your test suite (if you have one). This is the best way to catch subtle behavior changes in the ORM, templates, or views that manual testing might miss.
7. Repeat for each subsequent version until you reach 1.11.

Additional key considerations for your upgrade #

• Backup everything: Before starting any upgrade, make sure you have a full backup of your code and database. Better safe than sorry!
• Template system changes: Django 1.9+ enforces stricter template syntax rules. Check for things like misplaced {% load %} tags, deprecated template filters, or changes to admin template overrides.
• Middleware configuration: Django 1.10 introduced the new MIDDLEWARE setting (replacing MIDDLEWARE_CLASSES). While 1.11 still supports the old setting, take the time to switch to the new format during the 1.10→1.11 upgrade—it'll save you trouble in future upgrades.
• ORM tweaks: Keep an eye out for changes like the removal of Model._meta.get_field_by_name() in 1.9, or adjustments to QuerySet methods like exists() in 1.10. If you have complex custom queries, test them thoroughly.
• Admin interface changes: Deprecated admin options (like actions_on_top) were removed in later versions. Double-check any custom admin configurations to ensure they work as expected.

Once you're on 1.11 LTS, you'll have a stable base that's supported for a longer period, and you can consider upgrading to newer LTS versions (like 2.2 or 3.2) using the same step-by-step approach later.

内容的提问来源于stack exchange，提问作者Vincent