3 ms·
My experience has been that the easiest method is to to upgrade one minor release at once (e.g. in your case I'd do 1.11 -> 2.0 -> 2.1 -> 2.2 -> 3.0). This has
by jacobian 7y ago
My experience has been that the easiest method is to to upgrade one minor release at once (e.g. in your case I'd do 1.11 -> 2.0 -> 2.1 -> 2.2 -> 3.0). This has almost always gone quite smoothly, but it is somewhat tedious.
That said, jumping a bunch of releases (e.g. 1.11 -> 3.0) actually often works out just fine, especially if I've got good test coverage. It's just that when it doesn't work, it can be tricky to find out what's going wrong. That's because the release notes are typically written with just a single step in mind, so with a bunch of releases I find myself scrambling to figure out which set of notes I need to read.
- samwillis 7y agoI recently went from 1.11 -> 2.0 -> 2.1 -> 2.2 over the course of about a week, deploying to production each time we had all test passing to ensure there wasn't anything amiss. There were actually relatively few changes to get there, the upgrade to Python 3 was a bigger (albeit still manageable) change. I'm expecting very few changes to get onto Django 3.0, will probably wait till the first bug fix release though as it tends to catch a few things. The best thing to go is run the dev server with `python -Wd` to get the depreciation warnings, and fix them before each upgrade. Worked perfectly!