diff options
| author | Adam Johnson <me@adamj.eu> | 2020-01-21 12:02:14 +0000 |
|---|---|---|
| committer | Mariusz Felisiak <felisiak.mariusz@gmail.com> | 2020-01-21 13:03:00 +0100 |
| commit | a062d432a33fe1052cd85eb2902b5472daa4c5f3 (patch) | |
| tree | 5e87717762d8a695120d18c3c17d16648511b66a | |
| parent | 789de6050ae5afed2d8cbf59e12e9a08fa7811e6 (diff) | |
[3.0.x] Made examples concrete in upgrade documentation.
Backport of e4bc4f26b27122f5887a5eea811ff985d9ab8b8d from master
| -rw-r--r-- | docs/howto/upgrade-version.txt | 7 |
1 files changed, 4 insertions, 3 deletions
diff --git a/docs/howto/upgrade-version.txt b/docs/howto/upgrade-version.txt index 9ce0be2b16..007df6459c 100644 --- a/docs/howto/upgrade-version.txt +++ b/docs/howto/upgrade-version.txt @@ -33,10 +33,11 @@ the new Django version(s): Pay particular attention to backwards incompatible changes to get a clear idea of what will be needed for a successful upgrade. -If you're upgrading through more than one feature version (e.g. A.B to A.B+2), +If you're upgrading through more than one feature version (e.g. 2.0 to 2.2), it's usually easier to upgrade through each feature release incrementally -(A.B to A.B+1 to A.B+2) rather than to make all the changes for each feature -release at once. For each feature release, use the latest patch release (A.B.C). +(2.0 to 2.1 to 2.2) rather than to make all the changes for each feature +release at once. For each feature release, use the latest patch release (e.g. +for 2.1, use 2.1.15). The same incremental upgrade approach is recommended when upgrading from one LTS to the next. |