Upgrading Django to 1.8
Written by
oscarmlage
on
As they said, having last version has several benefits:
- New features and improvements are added.
- Bugs are fixed.
- Older version of Django will eventually no longer receive security updates.
- Upgrading as each new Django release is available makes future upgrades less painful by keeping your code base up to date.
Also it's even greater that 1.8 is a LTS
(Long-term support), that means we will get bug fixes and security updates for a guaranteed period of time, typically 3+ years.
How the upgrade has affected to some Django 1.4 production code?, hard to say in few words, it depends on how the code is (+ 3rd party pieces), but main spots - to take it carefully - I've noted were:
- Changes in how settings are organized, take a look to your settings and try to split it in environment files (tsd example).
- Migration tool is now builtin (not depending on South any more since 1.7), take care while migrating between migrating tool
:P
. - I've never used URL's with namespaces before
({% url 'namespace:view' %})
. It's a nice feature available in 1.4 too (didn't know) if you pretend to reuse an app in more than a project. - In urls.py
django.conf.urls.default
is becoming indjango.conf.urls
(from 1.6). - Cache key is now the ABSOLUTE URL (full request required to set/get a key).
- ManyToMany field warning related to the stupid
null=True
. - Query filtering by datetime has changed a bit.
- Changes in wsgi and gunicorn files (not using gunicorn_django any more).
- Don't forget to enable
ALLOWED_HOSTS
in your production settings (from 1.7).
It would be very tough if this above points pretend to be a guide or something like that. Not by a long shot. My recommendation is - of course - take a cup of your favourite drink, a bunch of patience... start reading the release notes and, above all, have as much fun as you can :)
.